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 2011/07/26 16:15:09 UTC

[jira] [Resolved] (COMPRESS-129) "java.io.EOFException: Truncated ZIP entry: "- while extracting a zip file that contains a entry which lager than 2 GB (Integer#MAX_VALUE)

     [ https://issues.apache.org/jira/browse/COMPRESS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Bodewig resolved COMPRESS-129.
-------------------------------------

    Resolution: Fixed

For non-ZIP64 entries, i.e. for ZIPs Commons Compress 1.2 can actually deal with, svn revision 1151104 should work.

The zip64 branch already contains the more general solution.

> "java.io.EOFException: Truncated ZIP entry: <some entry>"- while extracting a zip file that contains a entry which lager than 2 GB (Integer#MAX_VALUE)
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: COMPRESS-129
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-129
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.1
>         Environment: Ubuntu 10; java 6 of sun
>            Reporter: tinghui wang
>             Fix For: 1.2
>
>
> Issue:
> "java.io.EOFException: Truncated ZIP entry: <some entry>" will be threw while extracting a zip file that contains a entry with size larger than Integer#MAX_VALUE bytes (about 2 GB). After the big entry has been read, then try to get next entry by calling ZipArchiveInputStream#getNextZipEntry(), and it throws that EOFException.
> Cause:
> before getting next zip entry, ZipArchiveInputStream tries to close the current entry and in the close- method it use the field "bytesReadFromStream" to ensure all entry bytes are read, however the field "bytesReadFromStream" is a integer, that means it is already overflowed and it leads to a false ensure result.
> Solution suggestion:
> instead integer using long for "bytesReadFromStream" and possibly for "readBytesOfEntry" too.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira