[
https://issues.apache.org/jira/browse/COMPRESS-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306460#comment-16306460
]
Stefan Bodewig commented on COMPRESS-420:
-----------------------------------------
After looking through the archive once again I realized the LFH does actually
contain the correct compressed size, so something must have changed it. A
longish round of debugging later I realized it is your test code.
{code}
zipOutputStream.putArchiveEntry(new ZipArchiveEntry(entry));
{code}
puts the same {{ZipArchiveEntry}} instance to the output stream that is used by
the input stream. When {{zipOutputStream.closeArchiveEntry()}} is called, the
compressed size is overwritten (and is slightly different from the original)
and then the calculation in the input stream fails.
If you change your code to
{code}
zipOutputStream.putArchiveEntry(new ZipArchiveEntry(entry));
{code}
all three entries get extracted properly with 1.13 as well as the current
master branch.
> 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
> Fix For: 1.16
>
> 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)
