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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
