[
https://issues.apache.org/jira/browse/COMPRESS-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15867473#comment-15867473
]
Stefan Bodewig commented on COMPRESS-383:
-----------------------------------------
Ah, this is not a bug, unfortunately. It is the way ZIP archives work.
The entry you are trying to read doesn't store the file size inside the local
file header, which is valid. This is a case where the note in
http://commons.apache.org/proper/commons-compress/javadocs/api-1.13/org/apache/commons/compress/archivers/zip/ZipArchiveEntry.html#getSize()
applies:
{quote}
ZipArchiveInputStream may create entries that return SIZE_UNKNOWN as long as
the entry hasn't been read completely.
{quote}
{{SIZE_UNKNOWN}} is -1 and so you invoke {{read}} with a length of -1.
If you really need to know the size, don't use {{ZipArchiveInputStream}} but
{{ZipFile}} which reads the central directory located at the end of the archive
(and thus not accessible for {{ZipArchiveInputStream}}. It would likely be more
robust to loop over multiple reads anyway as there is no guarantee you'll get
the whole content of the entry with a single read, even if the size is known.
> ArrayIndexOutOfBoundsException in ZipArchiveInputStream.read
> ------------------------------------------------------------
>
> Key: COMPRESS-383
> URL: https://issues.apache.org/jira/browse/COMPRESS-383
> Project: Commons Compress
> Issue Type: Bug
> Affects Versions: 1.13
> Environment: OS X 10.11.6, Java 1.8.0_72
> Reporter: Mike Wertheim
> Attachments: test.zip, ZipCrash.java
>
>
> The attached zip file was created on Mac OS X (10.11.6) and is unzippable on
> Mac OS X.
> The attached java program demonstrates a crash in ZipArchiveInputStream.read
> when it tries to read this zip file.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
