[
https://issues.apache.org/jira/browse/COMPRESS-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16174324#comment-16174324
]
Stefan Bodewig commented on COMPRESS-420:
-----------------------------------------
{code}
$ zip -Tv ~/Downloads/missing-entry.zip
zip warning: expected 3 entries but found 0
zip error: Zip file structure invalid (/home/stefan/Downloads/missing-entry.zip)
$ java -jar target/commons-compress-1.15-SNAPSHOT.jar
~/Downloads/missing-entry.zip
Analysing /home/stefan/Downloads/missing-entry.zip
Created org.apache.commons.compress.archivers.zip.ZipArchiveInputStream@452b3a41
chop/
chop/slap-chop.png
chop/slap.jpg
{code}
I see three entries with {{ZipArchiveInputStream}} (which is what {{Lister}}
uses) but the archive doesn't seem to be valid at all. At least that's what
InfoZIP says.
When I use {{ZipFile}} of 1.14 (or the current git master) I get an
{{EOFException}} at the point where we start reading the central directory. It
looks as if the offset inside the "end of central directory header" was wrong.
Looking at it with a hex editor I see the offset is encoded as 0x11 0x48 0x02
0x00 which turns into 0x24811 or 149521 in decimal. Given the archive is less
than 70k in size this offset points outside of the archive, which also explains
why InfoZIP says it cannot find any entries.
So in short, your archive is corrupt, there is no regression in {{ZipFile}}.
Has this archive been created by Commons Compress?
> 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)
