[
https://issues.apache.org/jira/browse/COMPRESS-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14001479#comment-14001479
]
Stefan Bodewig commented on COMPRESS-282:
-----------------------------------------
I haven't looked at your example archive, yet, and likely won't find the time
to do so before the weekend, but here is a possible explanation:
ZIP archives store meta data in two different places, the local file header and
the central directory. The local file header (LFH) preceeds the actual file
data, the central directory (CD) is at the end of the archive. CD data is
authoritative, when it conflicts with LFH data. ZipFile reads the CD,
ZipArchiveInputStream does not as it cannot do so for (non-seekable) streams
without consuming the whole archive first. From your description it sounds as
if the LFH was filled with -1 and the real size was only stored in the CD. If
so the OS X ZIP Archiver's interpretation of the ZIP spec is likely different
from Commons Compress's interpretation.
No matter who is correct, we should try to adapt to the OSX Archiver's view, if
possible. For this we need to take a closer look at your archive. BTW does
your example archive contain anything sensitive or can we use it as a
regression test archive inside Compress' code base.
> ZipArchiveInputStream returning entries with size -1.
> -----------------------------------------------------
>
> Key: COMPRESS-282
> URL: https://issues.apache.org/jira/browse/COMPRESS-282
> Project: Commons Compress
> Issue Type: Bug
> Affects Versions: 1.8.1
> Reporter: Sebastian Pawlak
> Attachments: config-autostart-gnome-at-session.desktop.zip
>
>
> Files archived with OSX Zip Archiver have ZipArchiveEntries with size -1
> (ZipArchiveEntry.getSize) when reading using ZipArchiveInputStream. The same
> files are fine when reading using ZipFile class.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
