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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

JIRA jira@apache.org
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


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.

Reply | Threaded
Open this post in threaded view
|

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

JIRA jira@apache.org

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

Reply | Threaded
Open this post in threaded view
|

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

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/COMPRESS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769899#action_12769899 ]

Stefan Bodewig commented on COMPRESS-87:
----------------------------------------

I'll look into this - thanks for the testcase - but let me add that in general ZipFile should be preferred over ZipArchiveInputStream when reading  file since the later may return entries that aren't supposed to be there at all.  ZipFile should terminate with a reasonable exception for truncated ZIPs OOTB.

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

Reply | Threaded
Open this post in threaded view
|

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

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/COMPRESS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770900#action_12770900 ]

Antoni Mylka commented on COMPRESS-87:
--------------------------------------

I know, just that I need to crawl zips that aren't necessarily files (like zips attached to emails, or zips inside other zips). For this we have to use the stream and our crawler fell into an infinite loop waiting for the '-1' returned from read() method, and kept getting '0' instead. This is bad IMHO.

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

Reply | Threaded
Open this post in threaded view
|

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

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

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