[
https://issues.apache.org/jira/browse/COMPRESS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070406#comment-13070406
]
Stefan Bodewig commented on COMPRESS-129:
-----------------------------------------
should be fixed with svn revision 1150608 of the zip64 branch, will resolve
this issue once the branch is merged to trunk
> "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.3
>
>
> 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
