[jira] [Commented] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version

["Stefan Bodewig (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)