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.