Description
In the process of working with a large number of .zip archives from various sources, I ran into a problem when unpacking some of them.
Configuration
- Framework: .NET 5.0
- OS: Windows 10
- Architecture: x64
Regression?
No, there is a similar problem in .NET 4.7.2
Other information
ZipArchiveEntry.cs :: IsOpenable
// _compressedSize is (long) 4294967295 => ffffffffif(OffsetOfCompressedData+_compressedSize>_archive.ArchiveStream.Length){message=SR.LocalFileHeaderCorrupt;returnfalse;}ZipBlocks.cs :: TryReadBlock
booluncompressedSizeInZip64=uncompressedSizeSmall==ZipHelper.Mask32Bit;// trueboolcompressedSizeInZip64=compressedSizeSmall==ZipHelper.Mask32Bit;// trueboolrelativeOffsetInZip64=relativeOffsetOfLocalHeaderSmall==ZipHelper.Mask32Bit;// falsebooldiskNumberStartInZip64=diskNumberStartSmall==ZipHelper.Mask16Bit;// false
ZipBlocks.cs :: TryGetZip64BlockFromGenericExtraField
zip64Block._size=extraField.Size;ushortexpectedSize=0;if(readUncompressedSize)expectedSize+=8;// trueif(readCompressedSize)expectedSize+=8;// trueif(readLocalHeaderOffset)expectedSize+=8;// falseif(readStartDiskNumber)expectedSize+=4;// false// expectedSize is 16// zip64Block._size is 28if(expectedSize!=zip64Block._size)returnfalse;// unreachable code if(readUncompressedSize)zip64Block._uncompressedSize=reader.ReadInt64();if(readCompressedSize)zip64Block._compressedSize=reader.ReadInt64();
Here is the ZipInfo result for the given archive.
The archive is alive and correctly opened by all current archivers.
There is no zipfile comment.
End-of-central-directory record:
-------------------------------
Zip archive file size: 7414 (0000000000001CF6h)
Actual end-cent-dir record offset: 7316 (0000000000001C94h)
Expected end-cent-dir record offset: 7316 (0000000000001C94h)
(based on the length of the central directory and its expected offset)
This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 1 entry.
The central directory is 151 (0000000000000097h) bytes long,
and its (expected) offset in bytes from the beginning of the zipfile
is 7165 (0000000000001BFDh).
Central directory entry #1:
---------------------------
file.txt
offset of local header from start of archive: 0
(0000000000000000h) bytes
file system or operating system of origin: MS-DOS, OS/2 or NT FAT
version of encoding software: 4.5
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 4.5
compression method: deflated
compression sub-type (deflation): normal
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2021 Mar 13 18:11:52
32-bit CRC value (hex): 1b0e1343
compressed size: 7042 bytes
uncompressed size: 93523 bytes
length of filename: 37 characters
length of extra field: 68 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
non-MSDOS external file attributes: 000000 hex
MS-DOS file attributes (00 hex): none
The central-directory extra field contains:
- A subfield with ID 0x0001 (PKWARE 64-bit sizes) and 28 data bytes. The first
20 are: 53 6d 01 00 00 00 00 00 82 1b 00 00 00 00 00 00 00 00 00 00.
- A subfield with ID 0x000a (PKWARE Win32) and 32 data bytes. The first
20 are: 00 00 00 00 01 00 18 00 4b 75 22 0f 76 04 d7 01 4b 75 22 0f.
There is no file comment.
A similar problem was mentioned earlier, but it was related to large files:
#1094
Description
In the process of working with a large number of .zip archives from various sources, I ran into a problem when unpacking some of them.
Configuration
Regression?
No, there is a similar problem in .NET 4.7.2
Other information
ZipArchiveEntry.cs :: IsOpenable
ZipBlocks.cs :: TryReadBlock
ZipBlocks.cs :: TryGetZip64BlockFromGenericExtraField
Here is the ZipInfo result for the given archive.
The archive is alive and correctly opened by all current archivers.
A similar problem was mentioned earlier, but it was related to large files:
#1094