On 2010-02-12, Torsten Curdt <[email protected]> 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 structure. >> 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? Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
