You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Stefan Bodewig (JIRA)" <ji...@apache.org> on 2009/10/30 06:30:59 UTC

[jira] Resolved: (COMPRESS-87) ZipArchiveInputStream doesn't report the end of a truncated archive

     [ 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.