ebourg commented on issue #46:
URL:
https://github.com/apache/tomcat-jakartaee-migration/issues/46#issuecomment-1513807408
Digging further... my initial intuition of removing the ZIP64 extra field
does really work, I just didn't implement it correctly (I added it only to the
STORED branch of `migrateArchiveStreaming`, DEFLATED entries still had the
field).
Since the Ant jar task disables ZIP64 fields by default I think
`migrateArchiveStreaming` should scrap it (for jar files only). It could check
the size of the entry, but a 4GB entry in a jar file seems so unrealistic I'd
not bother handling that case.
Side note: Commons Compress is fine, but throws an exception with a
misleading message when `zip64mode` is set to `never`:
Exception in thread "main"
org.apache.commons.compress.archivers.zip.Zip64RequiredException: Archive's
size exceeds the limit of 4GByte.
at
org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.createCentralFileHeader(ZipArchiveOutputStream.java:766)
at
org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.writeCentralDirectoryInChunks(ZipArchiveOutputStream.java:1792)
at
org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.finish(ZipArchiveOutputStream.java:1031)
at
org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.close(ZipArchiveOutputStream.java:633)
This error may appear simply because the entry has a ZIP64 extra field, even
when no size limit is exceeded.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
