[
https://issues.apache.org/jira/browse/COMPRESS-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16174374#comment-16174374
]
Luke Quinane commented on COMPRESS-420:
---------------------------------------
I suspected that the ZIP was corrupt, I think that ZIP was created with WinZIP
from memory.
Even though it is corrupt, both entries can still be extracted though:
{noformat}luke@fireblanket:/tmp/test$ unzip missing-entry.zip
Archive: missing-entry.zip
error [missing-entry.zip]: missing 81920 bytes in zipfile
(attempting to process anyway)
creating: chop/
inflating: chop/slap-chop.png
inflating: chop/slap.jpg
luke@fireblanket:/tmp/test$ cd chop/
luke@fireblanket:/tmp/test/chop$ md5sum *
3164953cca668532a2f18868c908a1d6 slap-chop.png
d73326f4aee9d22a4ef3f99ce2fac6f4 slap.jpg{noformat}
And both entries were accessible in commons compress 1.12, and are accessible
in 7z. Given that, would it be possible to warn about the corruption, but still
attempt to read the entries out?
> Entry missing from ZIP
> ----------------------
>
> Key: COMPRESS-420
> URL: https://issues.apache.org/jira/browse/COMPRESS-420
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.13, 1.14
> Reporter: Luke Quinane
> Attachments: missing-entry.zip
>
>
> There seems to be some regression introduced in v1.13 which means that the
> second entry in the attached ZIP is no longer exposed via:
> '{{zipFile.getEntries();}}'.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
