[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16245339#comment-16245339 ] 

Stefan Bodewig commented on COMPRESS-427:
-----------------------------------------

According to https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT section 4.4.2

{quote}11 - MVS (OS/390 - Z/OS){quote}


> 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
>         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
(v6.4.14#64029)