[jira] [Commented] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version
[
https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910172#comment-16910172
]
Robin Schimpf commented on COMPRESS-479:
Hi Stefan, thanks for your work! The refactored version looks like a great
addition to the ExtraField parsing code.
> Unable to extract Zip with unknown UniCode path extra data version
> --
>
> Key: COMPRESS-479
> URL: https://issues.apache.org/jira/browse/COMPRESS-479
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Robin Schimpf
>Priority: Major
> Labels: zip
> Fix For: 1.19
>
> Attachments: unicode-test10509149899131946592.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following exception is thrown when the version of the UniCode path extra
> data version is not 1. 7-Zip and Windows Explorer will extract the attached
> file. The version in the file was changed via a Hex editor to provoke the
> error.
> {code:java}
> java.lang.RuntimeException: Error parsing extra fields for entry:
> %U20AC_for_Dollar.txt - Unsupported version [116] for UniCode path extra data.
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:626)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:315)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:408)
> at
> org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest.testZipFileReadsUnicodeFields(UTF8ZipFilesTest.java:186)
> ...
> Caused by: java.util.zip.ZipException: Unsupported version [116] for UniCode
> path extra data.
> at
> org.apache.commons.compress.archivers.zip.AbstractUnicodeExtraField.parseFromLocalFileData(AbstractUnicodeExtraField.java:172)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:180)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:620)
> {code}
> As I understand the specification in Section 4.6.8 and 4.6.9 when the version
> is unknown the information shoule be ignored.
> Changes MAY NOT be backward compatible so this extra field *SHOULD NOT be
> used if the version is not recognized*.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version
[
https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909642#comment-16909642
]
Stefan Bodewig commented on COMPRESS-479:
-
The discussion has lead to a refactoring of the whole extra field parsing area.
In either case, master now properly reds your archive. :)
> Unable to extract Zip with unknown UniCode path extra data version
> --
>
> Key: COMPRESS-479
> URL: https://issues.apache.org/jira/browse/COMPRESS-479
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Robin Schimpf
>Assignee: Stefan Bodewig
>Priority: Major
> Labels: zip
> Fix For: 1.19
>
> Attachments: unicode-test10509149899131946592.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following exception is thrown when the version of the UniCode path extra
> data version is not 1. 7-Zip and Windows Explorer will extract the attached
> file. The version in the file was changed via a Hex editor to provoke the
> error.
> {code:java}
> java.lang.RuntimeException: Error parsing extra fields for entry:
> %U20AC_for_Dollar.txt - Unsupported version [116] for UniCode path extra data.
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:626)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:315)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:408)
> at
> org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest.testZipFileReadsUnicodeFields(UTF8ZipFilesTest.java:186)
> ...
> Caused by: java.util.zip.ZipException: Unsupported version [116] for UniCode
> path extra data.
> at
> org.apache.commons.compress.archivers.zip.AbstractUnicodeExtraField.parseFromLocalFileData(AbstractUnicodeExtraField.java:172)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:180)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:620)
> {code}
> As I understand the specification in Section 4.6.8 and 4.6.9 when the version
> is unknown the information shoule be ignored.
> Changes MAY NOT be backward compatible so this extra field *SHOULD NOT be
> used if the version is not recognized*.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version
[
https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906518#comment-16906518
]
Stefan Bodewig commented on COMPRESS-479:
-
For now I've decided to move the decisions to the API of {{ZipArchiveEntry}}.
By default extra fields that Compress should support but we fail to parse will
be read and converted but if you really want to be strict, you can do so using
the new {{getExtraFields}} overload.
The master branch now reads your archive without problems, but certainly
doesn't use the unicode extra field.
I'll discuss on the dev list whether this is the way to go or whether people
see a better approach.
> Unable to extract Zip with unknown UniCode path extra data version
> --
>
> Key: COMPRESS-479
> URL: https://issues.apache.org/jira/browse/COMPRESS-479
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Robin Schimpf
>Assignee: Stefan Bodewig
>Priority: Major
> Labels: zip
> Fix For: 1.19
>
> Attachments: unicode-test10509149899131946592.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following exception is thrown when the version of the UniCode path extra
> data version is not 1. 7-Zip and Windows Explorer will extract the attached
> file. The version in the file was changed via a Hex editor to provoke the
> error.
> {code:java}
> java.lang.RuntimeException: Error parsing extra fields for entry:
> %U20AC_for_Dollar.txt - Unsupported version [116] for UniCode path extra data.
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:626)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:315)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:408)
> at
> org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest.testZipFileReadsUnicodeFields(UTF8ZipFilesTest.java:186)
> ...
> Caused by: java.util.zip.ZipException: Unsupported version [116] for UniCode
> path extra data.
> at
> org.apache.commons.compress.archivers.zip.AbstractUnicodeExtraField.parseFromLocalFileData(AbstractUnicodeExtraField.java:172)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:180)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:620)
> {code}
> As I understand the specification in Section 4.6.8 and 4.6.9 when the version
> is unknown the information shoule be ignored.
> Changes MAY NOT be backward compatible so this extra field *SHOULD NOT be
> used if the version is not recognized*.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version
[
https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838037#comment-16838037
]
Stefan Bodewig commented on COMPRESS-479:
-
Actually I haven't figured out how to do that best myself either. The code for
dealing with the parser error is in a branch COMPRESS-479 and has been sitting
in my work tree for a while. Unfortunately I'm not spending as much time on
Compress as would be needed to get to a closure here quickly.
My current line of thought was heading towards a lenient mode for the
stream/ZipFile but I'm not sure whether such a flag wouldn't somehow imply more
changes than "just" the parsing of extra fields.
> Unable to extract Zip with unknown UniCode path extra data version
> --
>
> Key: COMPRESS-479
> URL: https://issues.apache.org/jira/browse/COMPRESS-479
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.18
>Reporter: Robin Schimpf
>Priority: Major
> Fix For: 1.19
>
> Attachments: unicode-test10509149899131946592.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following exception is thrown when the version of the UniCode path extra
> data version is not 1. 7-Zip and Windows Explorer will extract the attached
> file. The version in the file was changed via a Hex editor to provoke the
> error.
> {code:java}
> java.lang.RuntimeException: Error parsing extra fields for entry:
> %U20AC_for_Dollar.txt - Unsupported version [116] for UniCode path extra data.
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:626)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:315)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:408)
> at
> org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest.testZipFileReadsUnicodeFields(UTF8ZipFilesTest.java:186)
> ...
> Caused by: java.util.zip.ZipException: Unsupported version [116] for UniCode
> path extra data.
> at
> org.apache.commons.compress.archivers.zip.AbstractUnicodeExtraField.parseFromLocalFileData(AbstractUnicodeExtraField.java:172)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:180)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:620)
> {code}
> As I understand the specification in Section 4.6.8 and 4.6.9 when the version
> is unknown the information shoule be ignored.
> Changes MAY NOT be backward compatible so this extra field *SHOULD NOT be
> used if the version is not recognized*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version
[
https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824143#comment-16824143
]
Robin Schimpf commented on COMPRESS-479:
Your idea sounds good to me. Seems to be better scalable for future versions
than my naive approach.
How can the parameter in {{ExtraFieldUtils#parse}} currently be controlled by
the user? All calls from ZipArchiveEntry are passing
{{UnparseableExtraField.READ}} and all calls in {{ExtraFieldUtils}} are using
{{UnparseableExtraField.THROW}}?
Would it be an option to introduce a general "strict" and a "lenient" mode
instead of just configure the behaviour of a small part of the extraction?
> Unable to extract Zip with unknown UniCode path extra data version
> --
>
> Key: COMPRESS-479
> URL: https://issues.apache.org/jira/browse/COMPRESS-479
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.18
>Reporter: Robin Schimpf
>Priority: Major
> Fix For: 1.19
>
> Attachments: unicode-test10509149899131946592.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following exception is thrown when the version of the UniCode path extra
> data version is not 1. 7-Zip and Windows Explorer will extract the attached
> file. The version in the file was changed via a Hex editor to provoke the
> error.
> {code:java}
> java.lang.RuntimeException: Error parsing extra fields for entry:
> %U20AC_for_Dollar.txt - Unsupported version [116] for UniCode path extra data.
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:626)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:315)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:408)
> at
> org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest.testZipFileReadsUnicodeFields(UTF8ZipFilesTest.java:186)
> ...
> Caused by: java.util.zip.ZipException: Unsupported version [116] for UniCode
> path extra data.
> at
> org.apache.commons.compress.archivers.zip.AbstractUnicodeExtraField.parseFromLocalFileData(AbstractUnicodeExtraField.java:172)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:180)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:620)
> {code}
> As I understand the specification in Section 4.6.8 and 4.6.9 when the version
> is unknown the information shoule be ignored.
> Changes MAY NOT be backward compatible so this extra field *SHOULD NOT be
> used if the version is not recognized*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version
[
https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822029#comment-16822029
]
Stefan Bodewig commented on COMPRESS-479:
-
I didn't realize our code was the one throwing the exception already, sorry.
It's been a while since I last looked at that part of the code base.
There are two ways to look at this, one is "I want to know if my archive
contains extra fields that don't adhere to the spec" and the other one is "I
don't care for errors in extra fields, give me the data". So far we've been on
the first side - see for example the handling for runtime exceptions at
https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/archivers/zip/ExtraFieldUtils.java#L184
I'm currently pondering the idea of making the behavior user controlled much
like the {{onUnparseableData}} argument to {{ExtraFieldUtis#parse}} and am
unsure about what should be the default. Making a more lenient parser that
catches exceptions and turns the extra fields causing exceptions into
{{UnrecognizedExtraField}} instances the default would break backwards
compatibility in a way, but likely in an acceptable way as the difference will
be we can read archives that have failed before.
> Unable to extract Zip with unknown UniCode path extra data version
> --
>
> Key: COMPRESS-479
> URL: https://issues.apache.org/jira/browse/COMPRESS-479
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.18
>Reporter: Robin Schimpf
>Priority: Major
> Fix For: 1.19
>
> Attachments: unicode-test10509149899131946592.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following exception is thrown when the version of the UniCode path extra
> data version is not 1. 7-Zip and Windows Explorer will extract the attached
> file. The version in the file was changed via a Hex editor to provoke the
> error.
> {code:java}
> java.lang.RuntimeException: Error parsing extra fields for entry:
> %U20AC_for_Dollar.txt - Unsupported version [116] for UniCode path extra data.
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:626)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:315)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:408)
> at
> org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest.testZipFileReadsUnicodeFields(UTF8ZipFilesTest.java:186)
> ...
> Caused by: java.util.zip.ZipException: Unsupported version [116] for UniCode
> path extra data.
> at
> org.apache.commons.compress.archivers.zip.AbstractUnicodeExtraField.parseFromLocalFileData(AbstractUnicodeExtraField.java:172)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:180)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:620)
> {code}
> As I understand the specification in Section 4.6.8 and 4.6.9 when the version
> is unknown the information shoule be ignored.
> Changes MAY NOT be backward compatible so this extra field *SHOULD NOT be
> used if the version is not recognized*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version
[
https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818944#comment-16818944
]
Robin Schimpf commented on COMPRESS-479:
I have seen a simliar file in our production environment. The attached file is
artificial but with the same version as the originial problematic file. I also
was unable to find out with which archiver the original file was created.
> Unable to extract Zip with unknown UniCode path extra data version
> --
>
> Key: COMPRESS-479
> URL: https://issues.apache.org/jira/browse/COMPRESS-479
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.18
>Reporter: Robin Schimpf
>Priority: Major
> Fix For: 1.19
>
> Attachments: unicode-test10509149899131946592.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following exception is thrown when the version of the UniCode path extra
> data version is not 1. 7-Zip and Windows Explorer will extract the attached
> file. The version in the file was changed via a Hex editor to provoke the
> error.
> {code:java}
> java.lang.RuntimeException: Error parsing extra fields for entry:
> %U20AC_for_Dollar.txt - Unsupported version [116] for UniCode path extra data.
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:626)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:315)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:408)
> at
> org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest.testZipFileReadsUnicodeFields(UTF8ZipFilesTest.java:186)
> ...
> Caused by: java.util.zip.ZipException: Unsupported version [116] for UniCode
> path extra data.
> at
> org.apache.commons.compress.archivers.zip.AbstractUnicodeExtraField.parseFromLocalFileData(AbstractUnicodeExtraField.java:172)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:180)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:620)
> {code}
> As I understand the specification in Section 4.6.8 and 4.6.9 when the version
> is unknown the information shoule be ignored.
> Changes MAY NOT be backward compatible so this extra field *SHOULD NOT be
> used if the version is not recognized*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version
[
https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818909#comment-16818909
]
Stefan Bodewig commented on COMPRESS-479:
-
Thanks Robin, are you seeing this in the wild or is this an artificial archive
you've created? I'm not asking to dismiss the issue, rather am curious whether
there is a version different from 1 that we should learn to support directly.
Right now I'm pondering a way to generalize the situation where extra field
implementations can signal they don't know how to handle this specific set of
data. In a way your PR does and extra fields signal this state by returning
{{null}} for the extra data. This approach throws away the extra field data and
I'd hope to find a way to preserve the original data (by capturing it inside
{{UnparseableExtraFieldData}} or {{UnrecognizedExtraField}}, maybe).
One way could be to throw a specific exception in {{parseFrom*Data}}I which
would be caught in {{ExtraFieldUtils.parse}}, but really I haven't spent enough
time thinking about how to achieve my goal without breaking APIs. This might be
the point where moving to Java 8 becomes worthwhile as a default method on
{{ZipExtraField}} would add real value, maybe there is a way without bumping
the Java requirement.
> Unable to extract Zip with unknown UniCode path extra data version
> --
>
> Key: COMPRESS-479
> URL: https://issues.apache.org/jira/browse/COMPRESS-479
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.18
>Reporter: Robin Schimpf
>Priority: Major
> Attachments: unicode-test10509149899131946592.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following exception is thrown when the version of the UniCode path extra
> data version is not 1. 7-Zip and Windows Explorer will extract the attached
> file. The version in the file was changed via a Hex editor to provoke the
> error.
> {code:java}
> java.lang.RuntimeException: Error parsing extra fields for entry:
> %U20AC_for_Dollar.txt - Unsupported version [116] for UniCode path extra data.
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:626)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:315)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:408)
> at
> org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest.testZipFileReadsUnicodeFields(UTF8ZipFilesTest.java:186)
> ...
> Caused by: java.util.zip.ZipException: Unsupported version [116] for UniCode
> path extra data.
> at
> org.apache.commons.compress.archivers.zip.AbstractUnicodeExtraField.parseFromLocalFileData(AbstractUnicodeExtraField.java:172)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:180)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:620)
> {code}
> As I understand the specification in Section 4.6.8 and 4.6.9 when the version
> is unknown the information shoule be ignored.
> Changes MAY NOT be backward compatible so this extra field *SHOULD NOT be
> used if the version is not recognized*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version
[
https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792505#comment-16792505
]
Robin Schimpf commented on COMPRESS-479:
I created a pull request on Github. Since I'm not very familiar with the
codebase I don't know if there are any sideeffects.
> Unable to extract Zip with unknown UniCode path extra data version
> --
>
> Key: COMPRESS-479
> URL: https://issues.apache.org/jira/browse/COMPRESS-479
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.18
>Reporter: Robin Schimpf
>Priority: Major
> Attachments: unicode-test10509149899131946592.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following exception is thrown when the version of the UniCode path extra
> data version is not 1. 7-Zip and Windows Explorer will extract the attached
> file. The version in the file was changed via a Hex editor to provoke the
> error.
> {code:java}
> java.lang.RuntimeException: Error parsing extra fields for entry:
> %U20AC_for_Dollar.txt - Unsupported version [116] for UniCode path extra data.
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:626)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:315)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:408)
> at
> org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest.testZipFileReadsUnicodeFields(UTF8ZipFilesTest.java:186)
> ...
> Caused by: java.util.zip.ZipException: Unsupported version [116] for UniCode
> path extra data.
> at
> org.apache.commons.compress.archivers.zip.AbstractUnicodeExtraField.parseFromLocalFileData(AbstractUnicodeExtraField.java:172)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:180)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:620)
> {code}
> As I understand the specification in Section 4.6.8 and 4.6.9 when the version
> is unknown the information shoule be ignored.
> Changes MAY NOT be backward compatible so this extra field *SHOULD NOT be
> used if the version is not recognized*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
