You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Luke Quinane (JIRA)" <ji...@apache.org> on 2017/12/05 05:10:00 UTC

[jira] [Commented] (COMPRESS-420) Entry missing from ZIP

    [ 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)