[
https://issues.apache.org/jira/browse/COMPRESS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoni Mylka updated COMPRESS-87:
---------------------------------
Attachment: apache-maven-2.2.1.zip.001
commons-compress-87.patch
A patch containing the two lines I talked about in the issue description as
well as a unit test.
The test file is a part of the Maven 2.2.1 distribution so it's already
copyrighted by ASF. It should be placed in src/test/resources folder
> 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
> 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.
