Zip64ExtraField should read StartDiskNumber as uint32

[eerhardt]

According to https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT:

4.4.1 General notes on fields

 4.4.1.1  All fields unless otherwise noted are unsigned and stored
 in Intel low-byte:high-byte, low-word:high-word order.

And the spec for the Zip64ExtraField doesn't note otherwise:

4.5.3 -Zip64 Extended Information Extra Field (0x0001):

   Disk Start
   Number     4 bytes    Number of the disk on which
                         this file starts 

However, we are reading the "Disk Start Number" as a signed int32, and then throwing an exception if the number is negative:

runtime/src/libraries/System.IO.Compression/src/System/IO/Compression/ZipBlocks.cs

Lines 209 to 218 in 33b7ed8

	if (readUncompressedSize) zip64Block._uncompressedSize = reader.ReadInt64();
	if (readCompressedSize) zip64Block._compressedSize = reader.ReadInt64();
	if (readLocalHeaderOffset) zip64Block._localHeaderOffset = reader.ReadInt64();
	if (readStartDiskNumber) zip64Block._startDiskNumber = reader.ReadInt32();
	// original values are unsigned, so implies value is too big to fit in signed integer
	if (zip64Block._uncompressedSize < 0) throw new InvalidDataException(SR.FieldTooBigUncompressedSize);
	if (zip64Block._compressedSize < 0) throw new InvalidDataException(SR.FieldTooBigCompressedSize);
	if (zip64Block._localHeaderOffset < 0) throw new InvalidDataException(SR.FieldTooBigLocalHeaderOffset);
	if (zip64Block._startDiskNumber < 0) throw new InvalidDataException(SR.FieldTooBigStartDiskNumber);

We should change this to zip64Block._startDiskNumber = reader.ReadUInt32();, remove the exception, and flow the uint value everywhere.

Looking at the reference source:

https://referencesource.microsoft.com/#WindowsBase/Base/MS/Internal/IO/Zip/ZipIOExtraFieldZip64Element.cs,101

That is reading as uint32 as well. We should update to the same.

Here is a prototype of the change: eerhardt@b790a94

[antara-gandhi]

hi there! @eerhardt is this issue still open?

[eerhardt]

Yes it is still open, but it looks like there is an active PR that will fix it - #83923.