The order of the fields in the zip64 extended
information record is fixed, but the fields MUST
only appear if the corresponding Local or Central
directory record field is set to 0xFFFF or 0xFFFFFFFF.
offset and disk number in the central directory entry are not set to all-1 values but the corresponding fields inside the extra information field are present - and make up for the 12 unexpected bytes.
It is also obvious that InfoZIP based implementations can deal with this kind of violation. I'll dig into their source code to see what sort of heuristic they use.
> ZipException on reading valid zip64 file
> Key: COMPRESS-228
> URL: https://issues.apache.org/jira/browse/COMPRESS-228 > Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.5
> Environment: java.runtime.name=OpenJDK Runtime Environment
> Reporter: Valerij Bancer
> Labels: zip, zip64
> Attachments: ordertest-64.zip
> ZipFile zip = new ZipFile(new File("ordertest-64.zip")); throws ZipException "central directory zip64 extended information extra field's length doesn't match central directory data. Expected length 16 but is 28".
> The archive was created by using DotNetZip-WinFormsTool uzing zip64 flag (forces always to make zip64 archives).
> Zip file is tested from the console: $zip -T ordertest-64.zip
> test of ordertest-64.zip OK
> I can open the archive with FileRoller without problem on my machine, browse and extract it.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira