commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [compress] Dealing with "invalid" extra fields in ZIPs
Date Fri, 12 Feb 2010 14:55:03 GMT
On 2010-02-12, Torsten Curdt <> wrote:

>> The semi-official ZIP standard recommends a format for this extra data
>> (two-byte tag, two-byte length of data, rest of data) and the current
>> ZIP classes in compress go a step further and enforce this
>> recommendation.

>> There are files out there that contain extra fields that do not follow
>> the recommendation.  You can find one attached to COMPRESS-62.

> So that's only a recommendation for a free form field?

Yes, it's an array of arbitrary many bytes with a recommended internal

>> When reading such a file InfoZIP's unzip simply ignores the extra fields
>> and issues a warning.  Our ZipFile and ZipArchiveEntry classes throw an
>> exception.

>> It wouldn't be too difficult to make the codebase ignore those fields as
>> well, but there are a few things to consider:

> Maybe we could introduce a boolean on whether we want to enforce this
> or not.
> Question is where this should be configured best and what the default
> behavior is.

The flag - if introduced - should be part of the stream classes and
ZipFile and apply to them as a whole.  When writing archives, you are
dealing with ZipArchiveEntry directly, though.

>> * do we want to log a warning?  Where to?

> Using logging is not really a great option for a library IMO.

Same here.

>> * do we want to accept invalid extra fields when writing ZIP entries as
>>  well?

> If it really is just a free form field then we should accept anything.
> Otherwise we should not encourage the creation of such files.

I agree.  Just state the recommended format in the javadocs?


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

View raw message