[jira] [Resolved] (COMPRESS-427) ZipFile.getEntries() returns WinZip entries separated by backslash

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

     [ https://issues.apache.org/jira/browse/COMPRESS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Bodewig resolved COMPRESS-427.
-------------------------------------
    Resolution: Won't Fix

The problem is WinZip and there is no good indicator we could use to identify a  name really has been broken by WinZip.

> ZipFile.getEntries() returns WinZip entries separated by backslash
> ------------------------------------------------------------------
>
>                 Key: COMPRESS-427
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-427
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.10, 1.15
>            Reporter: Yana Lebedeva
>            Priority: Major
>         Attachments: mdash-and-umlaut.zip
>
>
> Archives created by WinZip on Windows 10 display recurring COMPRESS-176 behaviour, with a new twist.
> Attached example archive is created by latest WinZip version 22 build 12663.
> It may have been experienced also for WinZip version 18 build 10661 on Windows 10.
> ZipFile.getEntries() for the attached example zip archive return the list of entries with the following ZipArchiveEntry.getName():
> {noformat}
> test/
> test\\file — mdash.txt
> test/ä.txt
> test/sub/
> test/sub\\file — mdash2.txt
> test/sub\\ä2.txt
> {noformat}
> ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
> It returns 0 for all entries in the example archive, except for two entries containing mdash. Those return 11.
> Tested with version 1.10 and updating to current 1.15.
> The backslash names seem to originate in the Unicode extra fields.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)