commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-227) duplicate entries may let ZipFile#getInputStream return null
Date Mon, 20 May 2013 15:35:17 GMT


Stefan Bodewig commented on COMPRESS-227:

One way to fix it is committed with svn revision 1484499
> duplicate entries may let ZipFile#getInputStream return null
> ------------------------------------------------------------
>                 Key: COMPRESS-227
>                 URL:
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.5
>            Reporter: Stefan Bodewig
>            Assignee: Stefan Bodewig
>              Labels: zip
>             Fix For: 1.6
> Found while investigating
> If an archive contains two entries for the same file readCentralDirectory in ZipFile
will only add the first entry to the entries map and only the last to the nameMap map - this
is because entries is a LinkedHashMap and nameMap is a "plain" HashMap.
> Normally this wouldn't matter since both ZipArchiveEntry instances are equal and thus
it is irrelevant which of the two is used as a key when obtaining the InputStream.
> Things get different, though, if the entry has data inside the local file header as only
the first entry is dealt with in resolveLocalFileHeaderData - after this the two instances
are no longer equal and nameMap.get(NAME) will return an instance that can no longer be found.
> I intend to modify readCentralDirectory to only add the first entry to nameMap as well
and document the behavior.  I'll also start a discussion thread on the dev list on whether
we need to provide an additional API with multiple entries per name.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message