[
https://issues.apache.org/jira/browse/COMPRESS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-87.
------------------------------------
Resolution: Fixed
Fix Version/s: 1.1
I had to modify the test a little since the byte-counts for some existing
entries were different on my Linux box (so I simply ignored them) and the first
read of the last entry succeeded (with a count > 0) for me.
Thanks!
svn revision 831204
> ZipArchiveInputStream doesn't report the end of a truncated archive
> -------------------------------------------------------------------
>
> Key: COMPRESS-87
> URL: https://issues.apache.org/jira/browse/COMPRESS-87
> Project: Commons Compress
> Issue Type: Bug
> Affects Versions: 1.0, 1.1
> Reporter: Antoni Mylka
> Assignee: Stefan Bodewig
> Fix For: 1.1
>
> Attachments: apache-maven-2.2.1.zip.001, commons-compress-87.patch
>
>
> If a Zip archive is truncated, (e.g. because it is the first volume in a
> multi-volume archive) the ZipArchiveInputStream.read() method will not detect
> that fact. All calls to read() will return 0 bytes read. They will not return
> -1 (end of stream), nor will they throw any exception (which would seem like
> a good idea to me because the archive is truncated).
> I have tracked this problem to ZipArchiveInputStream.java, line 239. It
> contains a check
> if (read == 0 && inf.finished()) {
> return -1;
> }
> For truncated archives the read is always zero but the inf is never
> finished(). I suggest adding two lines below:
> if (read == 0 && inf.finished()) {
> return -1;
> } else if (read == 0 && lengthOfLastRead == -1) {
> throw new IOException("Truncated ZIP file");
> }
> This solves the problem in my tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
