commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-129) "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)
Date Mon, 25 Jul 2011 09:55:18 GMT

    [ 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

        

Mime
View raw message