commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Tyler <>
Subject Re: Compress 1.1 release?
Date Fri, 12 Mar 2010 08:39:18 GMT

If I explain the scenario in more detail then it might become clearer.

I am seeing issues with certain zip files and file format based on zip (such
as docx and zip). We are reading these files from a stream so are using the

What I see is that we loop around getting each entry with getNextZipEntry
and we get a null and stop. All looks good. However we have only extracted 1
or 2 entries out of a known 20 or 30 entries - the file based extractor
extracts all the file.

I cannot provide an example of a file as the examples I have are all
customer owned. However every xps file I have seen suffers the issue:

I have investigated the issue and it is caused by entries that use the
central directory. What happens in the zip stream reader is that the size,
csize and crc fields are all zero, there is no central directory available
to the reader so it performs no extraction. This means the next loop to
getNextZipEntry is incorrectly positioned and fails checking the entry
signature (LFH_SIG), this returns a null and to the calling code it appears
that we have succeeded.

So my two change requests are simply to enable me to validate entries and
detect these types of stream so I can do something appropriate. With
compress 1.1 there is support to identify encrypted entries which I need and
hence the request to identify entries using the data descriptor.

The second request is to not return a null when this type of error occurs
but indicate the error somehow. There might be issues here (I am no zip
expert) but I would be worried about false errors being reported.


On 11/03/2010 13:11, "Stefan Bodewig" <> wrote:

> On 2010-03-10, Simon Tyler <> wrote:
>> Do we have a date yet for the compress 1.1 release?
> What Christian said.
>> Also, is there time to add a couple of minor feature enhancements? I could
>> do with access to the following:
>> 1. A public method to check if a ZipArchiveInputStream has a data
>> descriptor (e.g. return hasDataDescriptor).
> This is a property of the individual entry, not the stream as a whole,
> isn't it?  Why would you want to know that (just curious)?  We could
> probably make the general purpose flags available and you could look at
> bit 3.
>> 2. Better handling when ZipArchiveInputStream is used to read such streams.
>> Currently it silently fails when this happens when if hits an invalid
>> LFH_SIG by returning null.
> I'm not sure what you mean, could you describe what happens under what
> circumstances in more detail?  I see that the data descriptor isn't read
> anywhere and I see that the stream may fail if the data descriptor uses
> the "unofficial signature" mentioned in appnote, is this what you mean?
> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message