[
https://issues.apache.org/jira/browse/COMPRESS-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luke Quinane updated COMPRESS-420:
----------------------------------
Attachment: test.zip
It looks like I was a bit confused. My project already had some code to handle
the corruption earlier in the workflow, and it appears that is where the
regression is. It uses ZipArchiveInputStream to stream as many entries as
possible into a new ZIP file, and then that is read using zipFile.getEntries().
I've attached a new test case which works with 1.12, but fails with 1.14:
{noformat}C:\work\temp\test>java -cp
commons-compress-1.12.jar;commons-io-2.2.jar;. Test
Read: chop/
Read: chop/slap-chop.png
Read: chop/slap.jpg
Copied: 3{noformat}
{noformat}C:\work\temp\test>java -cp
commons-compress-1.14.jar;commons-io-2.2.jar;. Test
Read: chop/
Read: chop/slap-chop.png
Error: Unexpected record signature: 0XC2ED9440
java.util.zip.ZipException: Unexpected record signature: 0XC2ED9440
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:251)
at Test.main(Test.java:26)
Copied: 2{noformat}
Debugging through the ZipArchiveInputStream code, it looks like it reads
slightly too far past the second entry. When the signature for the third entry
is checked, it's invalid because the offset is off.
> 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)
