Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zip64 extension does not respect versionMadeBy/versionNeededToExtract settings at member level #51

farblos opened this issue Sep 17, 2019 · 6 comments


Copy link

commented Sep 17, 2019

The zip64 PR (my own, unfortunately) merged into version 1.66 uses hard-coded values to set attributes versionMadeBy and versionNeededToExtract when writing local and CD headers. It does not use the values available in the Archive::Zip::Member object.

I noticed that when trying to establish round-trip-equality, that is, read some arbitrary zip file with Archive::Zip, write it out again, and compare the result to the original one.

Not sure what an "ideal" solution to this problem would be.


This comment has been minimized.

Copy link
Contributor Author

commented Sep 18, 2019

The following logic seems reasonable:

  • for versionMadeBy, use default value 20 (45 for zip64 EOCD record) or any previously read value. Never change that value when writing.

  • likewise for versionNeededToExtract, but force a minimum value of 45 when writing headers in zip64 format or the zip64 EOCD record

Currently testing that logic ...


This comment has been minimized.

Copy link

commented Sep 18, 2019


This comment has been minimized.

Copy link

commented Sep 19, 2019

I checked a zip64 archive created with InfoZip, to see what it does.

First create a zip64 archive (the -fz option will force Zip64)

# zip -fz /tmp/ ~/.bashrc 
updating: root/.bashrc (deflated 29%)

Then dump the details (see below). The Extract Zip Spec is 2D (i.e. 45 decimal) in both the local and central headers, so that matches with what you arer proposing. The Created Zip Spec is 1E (i.e. decimal 30) in the central headers. That doesn't match what you are proposing. Can't find a definition of the 3.0 version in the PKWARE APPNOTE.

Interestingly, if I use InfoZip to create a non-Zip64 archive, it does use 14 (i.e. 20 decimal).

No idea what the rationale is behind that is.

# zipdetails /tmp/

0000 LOCAL HEADER #1       04034B50
0004 Extract Zip Spec      2D '4.5'
0005 Extract OS            00 'MS-DOS'
0006 General Purpose Flag  0000
     [Bits 1-2]            0 'Normal Compression'
0008 Compression Method    0008 'Deflated'
000A Last Mod Time         439D1350 'Sun Dec 29 02:26:32 2013'
000E CRC                   ADF27BAA
0012 Compressed Length     FFFFFFFF
0016 Uncompressed Length   FFFFFFFF
001A Filename Length       000C
001C Extra Length          0030
001E Filename              'root/.bashrc'
002A Extra ID #0001        5455 'UT: Extended Timestamp'
002C   Length              0009
002E   Flags               '03 mod access'
002F   Mod Time            52BF8857 'Sun Dec 29 02:26:31 2013'
0033   Access Time         5D822A9A 'Wed Sep 18 14:01:14 2019'
0037 Extra ID #0002        7875 'ux: Unix Extra Type 3'
0039   Length              000B
003B   Version             01
003C   UID Size            04
003D   UID                 00000000
0041   GID Size            04
0042   GID                 00000000
0046 Extra ID #0003        0001 'ZIP64'
0048   Length              0010
004A   Uncompressed Size   00000000000000B0
0052   Compressed Size     000000000000007D
005A PAYLOAD               M.;..0.E.:..'Q....y.Q.(...a$.d..O.)hOqu;

00D7 CENTRAL HEADER #1     02014B50
00DB Created Zip Spec      1E '3.0'
00DC Created OS            03 'Unix'
00DD Extract Zip Spec      2D '4.5'
00DE Extract OS            00 'MS-DOS'
00DF General Purpose Flag  0000
     [Bits 1-2]            0 'Normal Compression'
00E1 Compression Method    0008 'Deflated'
00E3 Last Mod Time         439D1350 'Sun Dec 29 02:26:32 2013'
00E7 CRC                   ADF27BAA
00EB Compressed Length     0000007D
00EF Uncompressed Length   FFFFFFFF
00F3 Filename Length       000C
00F5 Extra Length          0024
00F7 Comment Length        0000
00F9 Disk Start            0000
00FB Int File Attributes   0001
     [Bit 0]               1 Text Data
00FD Ext File Attributes   81A40000
0101 Local Header Offset   00000000
0105 Filename              'root/.bashrc'
0111 Extra ID #0001        5455 'UT: Extended Timestamp'
0113   Length              0005
0115   Flags               '03 mod access'
0116   Mod Time            52BF8857 'Sun Dec 29 02:26:31 2013'
011A Extra ID #0002        7875 'ux: Unix Extra Type 3'
011C   Length              000B
011E   Version             01
011F   UID Size            04
0120   UID                 00000000
0124   GID Size            04
0125   GID                 00000000
0129 Extra ID #0003        0001 'ZIP64'
012B   Length              0008
012D   Uncompressed Size   00000000000000B0

0135 ZIP64 END CENTRAL DIR 06064B50
0139 Size of record        000000000000002C
0141 Created Zip Spec      1E '3.0'
0142 Created OS            03 'Unix'
0143 Extract Zip Spec      2D '4.5'
0144 Extract OS            00 'MS-DOS'
0145 Number of this disk   00000000
0149 Central Dir Disk no   00000000
014D Entries in this disk  0000000000000001
0155 Total Entries         0000000000000001
015D Size of Central Dir   000000000000005E
0165 Offset to Central dir 00000000000000D7

0171 Central Dir Disk no   00000000
0175 Offset to Central dir 0000000000000135
017D Total no of Disks     00000001

0181 END CENTRAL HEADER    06054B50
0185 Number of this disk   0000
0187 Central Dir Disk no   0000
0189 Entries in this disk  0001
018B Total Entries         0001
018D Size of Central Dir   0000005E
0191 Offset to Central Dir FFFFFFFF
0195 Comment Length        0000


This comment has been minimized.

Copy link
Contributor Author

commented Sep 19, 2019

Thanks for the background infomation.

Since I couldn't make anything reasonable of the "2.0" and "3.0" for versionMadeBy/Created Zip Spec as well, I took them to be the version of InfoZip itself. It's only an educated guess, but at least it matches InfoZip's history: Large file support is available with InfoZip 3.0.

But anyway, I very much guess that no code actually cares about these values. My rationale for above logic was: Maintain round-trip equality where possible, but at least enforce the 45 for versionNeededToExtract/Extract Zip Spec in zip64 structures.

I added some short explanation on the logic to the POD as well (in "BUGS AND CAVEATS"), to have it at least documented.

farblos added a commit to farblos/perl-Archive-Zip that referenced this issue Sep 19, 2019

This comment has been minimized.

Copy link

commented Sep 23, 2019

Just an FYI we noticed this in Debian here:


This comment has been minimized.

Copy link
Contributor Author

commented Oct 8, 2019

Issue fixed in version 1.67.

@farblos farblos closed this Oct 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
4 participants
You can’t perform that action at this time.