commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
Date Wed, 10 Jan 2018 07:59:00 GMT


Stefan Bodewig commented on COMPRESS-380:

There is an additional danger when we add buffering inside of the compressor streams unconditionally:
we may read too far.

Take DEFLATE64, {{ZipArchiveInputStream}} and the case where a data descriptor is used as
an example.

When the deflater has found the "end of stream" marker it will return -1 and we are done.
An additional {{BufferedInputStream}} may have consumed additional bytes from the original
ZIP stream that we would now need to "push back" into the original stream so the rest of the
archive can be read properly.

Having multiple consecutive streams isn't that uncommon (multiple attachments of an email,
for example) that's why we need the caller to be able to control things.

COMPRESS-438 is a completely different case and I fully agree with it.

> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> ------------------------------------------------------
>                 Key: COMPRESS-380
>                 URL:
>             Project: Commons Compress
>          Issue Type: New Feature
>            Reporter: Dawid Weiss
>             Fix For: 1.16
>         Attachments:,,,,
compress-380.diff,, 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).

This message was sent by Atlassian JIRA

View raw message