> 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: [email protected] For additional commands, e-mail: [email protected]
