[
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16311099#comment-16311099
]
Stefan Bodewig commented on COMPRESS-380:
-----------------------------------------
[~chalmagr84] I'd like to remove the {{uncompressedSize}} from the stream's
constructor for two reasons:
* ze.getSize() when using the stream in a {{ZipArchiveInputStream}} context the
uncompressed size may be unknown as it may be stpred inside of a data
descriptor rather than the local file header
* the stream only uses it inside of {{available}} which is supposed to return
the number of bytes that can be read without blocking. The implementation of
{{available}} is probably not correct for general {{InputStream}}s as we may
well be blocking while trying to read bits from it, it is probably OK for the
seekable input underlying {{ZipFile}}
I'd make {{available}} return 0 unconditionally. Alternatively the
{{DecoderState}}s may know a bit more about data they have already read and
could provide a less pessimistic answer.
Any objections?
> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> ------------------------------------------------------
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
> Issue Type: New Feature
> Reporter: Dawid Weiss
> Fix For: 1.16
>
> Attachments: archive-deflate.zip, archive-deflate64.zip, archive.zip,
> archive64.zip, compress-380.diff, hello.world, input2
>
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method
> 'ENHANCED_DEFLATED'
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64.
> This seems to be PKWare's extensions, although code to decrypt it exists in
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
