The enum makes sense. Are there any feasible ways to, say, configure some sort of handler class that can implement logic around unknown fields? Sort of an extensibility model there, but hopefully without having to extend ZipInputStream or anything like that.
On Tue, 13 Aug 2019 at 14:01, Stefan Bodewig <[email protected]> wrote: > > Hi > > https://issues.apache.org/jira/browse/COMPRESS-479 highlights a problem > where our zip reading code may reject an archive because it uses extra > fields that we only partially understand. In this case the archive is > not a real one, but it is easy to envision extra fields in the wild that > use more advanced versions than we currently support. > > For most of our users the ZIP extra fields will be noise and they really > are only interested in the actual content of the archives. > > Therefore I have decided to treat any such "not quite as we expect" > extra field the same way as any "we have no idea how this extra field > looks internally" field - i.e. just store it but don't try to parse > it. > > In addition I have provided an API inside of ZipArchiveEntry that allows > users to specify in detail how strict they want the extra field parsing > to be. > > Does this make sense to you? Would you recommend taking a different > approach? And it if makes sense, are the enum names I've chosen in > https://github.com/apache/commons-compress/blob/2bf678bbc6c6002569559b90ea29a031f035f067/src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveEntry.java#L1117 > understandable? > > Thanks > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Matt Sicker <[email protected]> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
