commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <j...@apache.org>
Subject [jira] Reopened: (COMPRESS-94) Creating zip files with many entries will ocassionally produce corrupted output
Date Thu, 07 Jan 2010 09:50:14 GMT

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

Stefan Bodewig reopened COMPRESS-94:
------------------------------------


Ant's codebase didn't have the same problem since Ant's ZipEntry class has a completely different
implementation of equals (basically Object#equals).

I'm not convinced that CC's equals implementation is a good idea since it only takes an entry's
name into account and nothing else (size, extra fields, compression mode, last modified date
and all that).


> Creating zip files with many entries will ocassionally produce corrupted output
> -------------------------------------------------------------------------------
>
>                 Key: COMPRESS-94
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-94
>             Project: Commons Compress
>          Issue Type: Bug
>    Affects Versions: 1.0
>         Environment: Windows 2003 Server 64 bit, Java 6.0
>            Reporter: Anon Devs
>            Assignee: Stefan Bodewig
>             Fix For: 1.1
>
>         Attachments: COMPRESS-94.patch
>
>
> Our application produces large numbers of zip files, often with 1000's of similarly named
files contained within the zip. 
> When we switched from the standard JDK zip classes to those in commons compress, we would
ocassionally produce a zip file that had corrupted index entries and would fail to unzip successfully
using 7-zip, winzip, etc.
> Debugging the zip creation showed that the the wrong offsets were being returned from
the hashmap in ZipOutputStream for the entries that were being corrupted.  Further analysis
revealed that this occurred when the filenames being added had a hash collision with another
entry in the same output zip (which appears to happen quite frequently for us).
> The issue appears to stem from the fact that ZipArchiveEntry can store the entry name
either in its superclass if passed in on the ctor or in its own member attribute if set later
via setName().  Not sure whether this functionality is really required?  Regardless, the root
cause of the bug is that the equals() and hashCode() methods in ZipArchiveEntry do not always
use the same filename value in their comparisons.  In fact if the filename of the entry is
set in the ctor it will always treat two ZipArchiveEntries as equal.  This will break the
offset hashmap whenever there is a hash collision as it will overwrite the previous entry,
believeing it to be equal.
> Patch to follow.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message