Read StartDiskNumber as uint32

[mruslan97]

• The startDiskNumber field has been changed according to the zip specification.
• Added test with the archive where the value of startDiskNumber greater than int.MaxValue.

Fix #31825

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

Issue Details

---

• The startDiskNumber field has been changed according to the zip specification.
• Added test with the archive where the value of startDiskNumber greater than int.MaxValue.

Fix #31825

Author:	mruslan97
Assignees:	-
Labels:	area-System.IO.Compression
Milestone:	-

[danmoseley]

looks good to me except couple things

[danmoseley]

Rather than duplicate this whole thing what about just flipping the byte you need, within the test?

[mruslan97]

Good point, i'll try. But I changed quite a few bytes in different parts(https://www.diffchecker.com/YK5V7XvS), so any advice would be helpful for me how to do it better

[danmoseley]

I almost wonder then whether it would make sense to extract that "proto zip" data into a mock with a method like SetStartDiskNumber. That would make it cleaner to use and easier to maintain and extend.
It could in future eg abstract the ability to add more entries, which is more than just flipping some bytes, and maybe in future expose ways to get the bytes corrupted in interesting ways, without the tests knowing about the structure.

[mruslan97]

If I understand your idea correctly. We take s_slightlyIncorrectZip64 as a basis and create extensions for it such as SetStartDiskNumber? (and smth like SetCustomHeaderField in future)

[danmoseley]

yes -- I mean, I created that for a particular test and I see it's getting used in another place, now you needed it here and had to make larger edits as you say. But those tests shouldn't need to know the zip format.

So I wonder whether that suggests it would be helpful to wrap the array in a class that exposes it and that class can take care of any modifications a test needs. For now if nothing else you could just paste your new array in there, alongside the other one, but it would be a start.

If you don't want to do that here, I think what you have is fine. (I'll let area owners sign off though)

[mruslan97]

To be honest, I don't have an idea for a good implementation of this right now. It is complicated by the fact that different tests use different initialization methods (zip files in ZipTestData, byte arrays through MemberData or static byte arrays)

In my vision, it would look something like this:

var zipFile = FluentZipFileGenerator.CreateBuilder()
		.GetDefaultZipTemplate()
		.SetZip64ExtraFieldSize(args)
		.SetStartDiskNumber(args)
		.GenerateZipFile();

In this PR I can move the archive to ZipTestData/StrangeZipFiles folder.

[danmoseley]

@dotnet/area-system-io-compression would have to say what they would like. I don't have any strong opinion

[mruslan97]

Maybe we should tag someone else?

[adamsitnik]

https://github.com/orgs/dotnet/teams/area-system-io-compression would have to say what they would like. I don't have any strong opinion

As an ex-owner who is trying to review all stale PRs I think the PR is acceptable in the current state.

I like the concept of a builder than @mruslan97 proposed, but it can be a separate PR (let's don't block the fix anymore).

@mruslan97 as soon as you accept the CLA (#83923 (comment)) I am going to merge the PR.

@mruslan97 last, but not least big thanks for your contribution!

[danmoseley]

thanks, apologies for losing track of this one

[mruslan97]

@dotnet-policy-service agree

[danmoseley]

rerunning tests

[adamsitnik]

The failures are unrelated (#dotnet/arcade#11683, #76454), merging!

[danmoseley]

Thanks @mruslan97 for the contribution. We'd welcome another contribution in an area that interests you! Usually PRs go in faster than this one.

[mruslan97]

Thank you guys! When I get some free time I'll try to do something even more useful in future