[jira] [Commented] (COMPRESS-394) [Zip] Local `Version Needed To Extract` does not match Central Directory
[
https://issues.apache.org/jira/browse/COMPRESS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16020708#comment-16020708
]
Stefan Bodewig commented on COMPRESS-394:
-
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
> Labels: zip
> Fix For: 1.15
>
>
> 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)
[jira] [Commented] (COMPRESS-394) [Zip] Local `Version Needed To Extract` does not match Central Directory
[
https://issues.apache.org/jira/browse/COMPRESS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16020108#comment-16020108
]
Plamen Totev commented on COMPRESS-394:
---
Thanks. I've tried it and the version fields are consistent.
> [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
> Labels: zip
> Fix For: 1.15
>
>
> 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)
[jira] [Commented] (COMPRESS-394) [Zip] Local `Version Needed To Extract` does not match Central Directory
[
https://issues.apache.org/jira/browse/COMPRESS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16013035#comment-16013035
]
Stefan Bodewig commented on COMPRESS-394:
-
Don't worry, Plamen. Thank you for your detailed analysis.
> [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
> Labels: zip
> Fix For: 1.15
>
>
> 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)
[jira] [Commented] (COMPRESS-394) [Zip] Local `Version Needed To Extract` does not match Central Directory
[
https://issues.apache.org/jira/browse/COMPRESS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16012922#comment-16012922
]
Plamen Totev commented on COMPRESS-394:
---
Stefan, thank you for looking into this and COMPRESS-395, really appreciate it
and the fast reaction. I know that both does not have big impact but still some
tools issue warnings about that.
I really would love to help with patches but I'm in the middle of writing my
master thesis, so I afraid I don't have the time :(
> [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
> Labels: zip
> Fix For: 1.15
>
>
> 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)
[jira] [Commented] (COMPRESS-394) [Zip] Local `Version Needed To Extract` does not match Central Directory
[
https://issues.apache.org/jira/browse/COMPRESS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16012724#comment-16012724
]
Stefan Bodewig commented on COMPRESS-394:
-
git commit 8a6bb56 "fixes" the problem by using version 2.0 when DEFLATE is
used. But this is only an incomplete solution and I'll tackle the rest together
with COMPRESS-395 (if we don't write a data descriptor then we need to
transport this information in some way).
> [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
> Labels: zip
> Fix For: 1.15
>
>
> 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)
[jira] [Commented] (COMPRESS-394) [Zip] Local `Version Needed To Extract` does not match Central Directory
[
https://issues.apache.org/jira/browse/COMPRESS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16010705#comment-16010705
]
Stefan Bodewig commented on COMPRESS-394:
-
forget the part about 4.4.3.3 on second read I see it talks about the "end of
central directory record", not the central directory entry.
> [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)
[jira] [Commented] (COMPRESS-394) [Zip] Local `Version Needed To Extract` does not match Central Directory
[
https://issues.apache.org/jira/browse/COMPRESS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (COMPRESS-394) [Zip] Local `Version Needed To Extract` does not match Central Directory
[
https://issues.apache.org/jira/browse/COMPRESS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16009525#comment-16009525
]
Gary Gregory commented on COMPRESS-394:
---
Hi Plamen,
We are in the middle of releasing version 1.14 ATM, which should hit the site
in a couple of days at the most.
We welcome patches with unit tests :-)
Gary
> [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)
