[
https://issues.apache.org/jira/browse/COMPRESS-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16278023#comment-16278023
]
Luke Quinane commented on COMPRESS-420:
---------------------------------------
In our case, we've already detected that the ZIP is corrupted, and this is our
fallback code trying to pull out as much information as possible. Essentially a
'data-recovery' mode. As you can see in the attached test code, even catching
Exception doesn't allow that second file to be extracted, so it really is a
regression for us.
Perhaps there is some way we could call the API or flag to the ZIP code that
we're really not worried about whether the file is corrupt, we just want to get
as much data as possible. Or alternately, if you could register a listener to
receive errors as the extraction is occurring, and flag whether to stop or not?
> 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, test.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)
