Menu
▾
▴
1 Attachments
#61 Creating a badly-formed Zip64 zip file containing a single directory
If I force the creation of a Zip64 zip file that just contains a single directory, none of the expected Zip64 records are populated in the central directory. All the other Zip64 parts are created normally.
I can reproduce this with both zip 3.0 & zip 3.1.d-BETA.
Reproduce the issue like this.
First create the zip file (see attached)
$ mkdir fred $ zip -fz fred.zip fred adding: fred/ (stored 0%)
Let's see what zip thinks about it
$ zip -l fred.zip
zip warning: expected 1 entries but found 0
zip error: Zip file structure invalid (fred.zip)
and unzip
$ unzip -l fred.zip Archive: fred.zip error [fred.zip]: missing 4294967212 bytes in zipfile (attempting to process anyway) Length Date Time Name --------- ---------- ----- ---- 0 2020-03-29 14:59 fred/ --------- ------- 0 1 file
Let's have a look inside the zip file. The End of Central Directory Record has the offset to start of central directory set to FFFFFFFF as expected, but both the Zip64 end of central directory locator and Zip64 end of central directory record are missing. everything else looks ok for a Zip64 zip file.
$ zipdetails --scan fred.zip 0000 LOCAL HEADER #1 04034B50 0004 Extract Zip Spec 2D '4.5' 0005 Extract OS 00 'MS-DOS' 0006 General Purpose Flag 0000 0008 Compression Method 0000 'Stored' 000A Last Mod Time 507D7765 'Sun Mar 29 14:59:10 2020' 000E CRC 00000000 0012 Compressed Length FFFFFFFF 0016 Uncompressed Length FFFFFFFF 001A Filename Length 0005 001C Extra Length 0030 001E Filename 'fred/' 0023 Extra ID #0001 5455 'UT: Extended Timestamp' 0025 Length 0009 0027 Flags '03 mod access' 0028 Mod Time 5E80A9AE 'Sun Mar 29 14:59:10 2020' 002C Access Time 5E80A9AE 'Sun Mar 29 14:59:10 2020' 0030 Extra ID #0002 7875 'ux: Unix Extra Type 3' 0032 Length 000B 0034 Version 01 0035 UID Size 04 0036 UID 000003E8 003A GID Size 04 003B GID 000003E8 003F Extra ID #0003 0001 'ZIP64' 0041 Length 0010 0043 Uncompressed Size 0000000000000000 004B Compressed Size 0000000000000000 0053 PAYLOAD 0053 CENTRAL HEADER #1 02014B50 0057 Created Zip Spec 1E '3.0' 0058 Created OS 03 'Unix' 0059 Extract Zip Spec 0A '1.0' 005A Extract OS 00 'MS-DOS' 005B General Purpose Flag 0000 005D Compression Method 0000 'Stored' 005F Last Mod Time 507D7765 'Sun Mar 29 14:59:10 2020' 0063 CRC 00000000 0067 Compressed Length 00000000 006B Uncompressed Length FFFFFFFF 006F Filename Length 0005 0071 Extra Length 0024 0073 Comment Length 0000 0075 Disk Start 0000 0077 Int File Attributes 0000 [Bit 0] 0 'Binary Data' 0079 Ext File Attributes 41FD0010 [Bit 4] Directory 007D Local Header Offset 00000000 0081 Filename 'fred/' 0086 Extra ID #0001 5455 'UT: Extended Timestamp' 0088 Length 0005 008A Flags '03 mod access' 008B Mod Time 5E80A9AE 'Sun Mar 29 14:59:10 2020' 008F Extra ID #0002 7875 'ux: Unix Extra Type 3' 0091 Length 000B 0093 Version 01 0094 UID Size 04 0095 UID 000003E8 0099 GID Size 04 009A GID 000003E8 009E Extra ID #0003 0001 'ZIP64' 00A0 Length 0008 00A2 Uncompressed Size 0000000000000000 00AA END CENTRAL HEADER 06054B50 00AE Number of this disk 0000 00B0 Central Dir Disk no 0000 00B2 Entries in this disk 0001 00B4 Total Entries 0001 00B6 Size of Central Dir 00000057 00BA Offset to Central Dir FFFFFFFF <=========== 00BE Comment Length 0000 Done
This looks the same as bug #68. As noted there, the --force option seems to be working, but the code that creates the Zip64 headers is not being told to do that.
Adding this bug to the queue of Zip bugs to work. It should be a fairly quick fix, but no telling when we'll get Zip 3.1 out with it.