commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-164) Cannot Read Winzip Archives With Unicode Extra Fields
Date Mon, 05 Dec 2011 16:34:40 GMT

    [ https://issues.apache.org/jira/browse/COMPRESS-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162869#comment-13162869
] 

Stefan Bodewig commented on COMPRESS-164:
-----------------------------------------

It was easier and cleaner to fix in Ant's code base where nobody cares for the order of entries
from the central directory.

See svn revision 1210522
                
> Cannot Read Winzip Archives With Unicode Extra Fields
> -----------------------------------------------------
>
>                 Key: COMPRESS-164
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-164
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.3
>         Environment: Windows 7, Oracle JDK 6
>            Reporter: Volker Leidl
>             Fix For: 1.4
>
>         Attachments: UTF8ZipFilesTest.patch, ZipFile.patch
>
>
> I have a zip file created with WinZip containing Unicode extra fields. Upon attempting
to extract it with org.apache.commons.compress.archivers.zip.ZipFile, ZipFile.getInputStream()
returns null for ZipArchiveEntries previously retrieved with ZipFile.getEntry() or even ZipFile.getEntries().
See UTF8ZipFilesTest.patch in the attachments for a test case exposing the bug. The original
test case stopped short of trying to read the entries, that's why this wasn't flagged up before.

> The problem lies in the fact that inside ZipFile.java entries are stored in a HashMap.
However, at one point after populating the HashMap, the unicode extra fields are read, which
leads to a change of the ZipArchiveEntry name, and therefore a change of its hash code. Because
of this, subsequent gets on the HashMap fail to retrieve the original values.
> ZipFile.patch contains an (admittedly simple-minded) fix for this problem by reconstructing
the entries HashMap after the Unicode extra fields have been parsed. The purpose of this patch
is mainly to show that the problem is indeed what I think, rather than providing a well-designed
solution.
> The patches have been tested against revision 1210416.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message