commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-228) ZipException on reading valid zip64 file
Date Sun, 26 May 2013 17:08:21 GMT

    [ https://issues.apache.org/jira/browse/COMPRESS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667353#comment-13667353
] 

Stefan Bodewig commented on COMPRESS-228:
-----------------------------------------

To me it is quite clear that the archive you've attached violates the spec of http://www.pkware.com/documents/casestudies/APPNOTE.TXT
section 4.5.3

{quote}
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.
{quote}

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
> java.home=/usr/lib/jvm/java-6-openjdk-amd64/jre
> java.runtime.version=1.6.0_27-b27
> commons-compress-1.5
>            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
> Output:
> 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

Mime
View raw message