commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: [compress] Dealing with "invalid" extra fields in ZIPs
Date Fri, 12 Feb 2010 14:32:21 GMT
> 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?

> 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.

> * currently the Javadocs of ZipArchiveEntry#setExtra says "Throws an
>  Exception if extra data cannot be parsed into extra fields."
>
>  Either we change the Javadocs or we add a different method that does
>  not throw an exceptions, I'm not sure.
>
> * do we want to log a warning?  Where to?

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

> * 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.

IMO

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message