[jira] [Commented] (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)

["Stefan Bodewig (JIRA)" <ji...@apache.org>]

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

Stefan Bodewig commented on COMPRESS-129:
-----------------------------------------

Should be (at least partially) be resolved by svn revision 1149029

I agree with Sebb that a more complete fix is not possible without requiring Java5.  This will become more pressing if we start to support ZIP64 so I'll kick of a thread for this on the dev list later.

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