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-394) [Zip] Local `Version Needed To Extract` does not match Central Directory
Date Mon, 15 May 2017 15:27:04 GMT

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

Stefan Bodewig commented on COMPRESS-394:
-----------------------------------------

One could argue the current implementation was right as you don't need to support data descriptors
if you've read the central directory. But I must admit I don't recall whether the current
logic is as it is because of something like this or is that way by accident.

If you look at section 4.4.3.3 in https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
the last paragraph

{quote}
        When using ZIP64 extensions, the corresponding value in the
        zip64 end of central directory record MUST also be set.  
{quote}

this implies the values inside the local file header and the central directory can be different.
Not sure why infozip compains about it. Anyway, we should probably make things consistent.

And you are certainly correct, APPNOTE lists "DEFLATE" as version 2.0. I've got no idea why
we use 1.0, it's always been that way :-)

Thanks!

> [Zip] Local `Version Needed To Extract` does not match Central Directory
> ------------------------------------------------------------------------
>
>                 Key: COMPRESS-394
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-394
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>            Reporter: Plamen Totev
>            Priority: Minor
>
> Hi,
> This is followup on an issue reported on Plexus Archiver - https://github.com/codehaus-plexus/plexus-archiver/issues/57
> Plexus Archiver uses {{ZipArchiveOutputStream}} to create zip archives. It constructs
the {{ZipArchiveOutputStream}} using {{BufferedOutputStream}}. As a result the output do not
provide random access and additional data descriptor records are added. Unfortunately this
leads to different values being set for {{version needed to extract}} field in the local file
header and in the central directory. It looks like that the root cause is the way the local
header {{version needed to extract}} field value is calculated:
> {code:java}
>         if (phased &&  !isZip64Required(entry.entry, zip64Mode)){
>             putShort(INITIAL_VERSION, buf, LFH_VERSION_NEEDED_OFFSET);
>         } else {
>             putShort(versionNeededToExtract(zipMethod, hasZip64Extra(ze)), buf, LFH_VERSION_NEEDED_OFFSET);
>         }
> {code}
> As you can see the need for data descriptors is not taken into account. On other hand
when the central directory is created the following is used to determine the minimum required
version
> {code:java}
>     private int versionNeededToExtract(final int zipMethod, final boolean zip64) {
>         if (zip64) {
>             return ZIP64_MIN_VERSION;
>         }
>         // requires version 2 as we are going to store length info
>         // in the data descriptor
>         return (isDeflatedToOutputStream(zipMethod)) ?
>                 DATA_DESCRIPTOR_MIN_VERSION :
>                 INITIAL_VERSION;
>     }
> {code}
> As a side note: I'm not a zip expert by any means so I could be wrong, but my understanding
is that if Deflate compression is used then the minimum required version should be 2.0 regardless
if data descriptors are used or not.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message