[
https://issues.apache.org/jira/browse/COMPRESS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694028#action_12694028
]
Stefan Bodewig commented on COMPRESS-67:
----------------------------------------
ZIP has a feature that is called the data descriptor.
When your entry uses the DEFLATE method, you don't have to provide the size
(and CRC) information inside the local file header because the compression
algorithm itself will signal when you've read all data. In that case the size
information will be inside the ZIP after the entry's data (and you can check
whether the size/CRC matched what you've read).
Unfortunately this means you have to read the full entry in order to provide
the size information, which we cannot really do in a stream (without buffering
and running the risk of causing OOM exceptions for really big entries).
ZipFile can and does provide the correct information.
I don't see any way to fix this, but we certainly have to document it - and
list it as another reason prefer ZipFile over ZipArchiveInputStream.
ZipArchiveInputStream will set the correct size and CRC information inside the
LFH when it knows it is writing to a file, but it will also use the data
descriptor so ZipArchiveInputStream won't trust that information.
> ZipArchiveInputStream fails to call setSize() when reading archives created
> by ZipArchiveOutputStream
> -----------------------------------------------------------------------------------------------------
>
> Key: COMPRESS-67
> URL: https://issues.apache.org/jira/browse/COMPRESS-67
> Project: Commons Compress
> Issue Type: Bug
> Reporter: Sebb
>
> ZipArchiveInputStream fails to call setSize() when reading archives created
> by ZipArchiveOutputStream
> I'm not exactly sure where the problem is - looks to be something to do with:
> {code}
> getNextZipEntry(){
> ...
> if (!hasDataDescriptor) {
> // calls setSize()
> } else {
> // does not call setSize()
> }
> {code}
> Maybe the DataDescriptor is not being processed, or maybe there is no
> descriptor and the flag is set wrongly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
