[jira] [Comment Edited] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files

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

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

Stefan Bodewig edited comment on COMPRESS-380 at 1/4/18 9:56 AM:
-----------------------------------------------------------------

[~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?


was (Author: bodewig):
[~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)