[
https://issues.apache.org/jira/browse/COMPRESS-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14008388#comment-14008388
]
Stefan Bodewig commented on COMPRESS-282:
-----------------------------------------
I'll close this as it is not a bug but a known limitation, and also admit this
limitation has never been spelt out explicitly so I'll fix that first.
Your archive uses so called Data Descriptors, a feature that allows the size
and CRC information to be stored after the entry. Since ZipArchiveInputStream
cannot use random access it won't know the size of the entry until after it has
read the whole entry and reached the data desctriptor - i.e. until it is
positioned at the next entry.
{code}
FileInputStream fis = new FileInputStream(args[0]);
ZipArchiveInputStream zis = new ZipArchiveInputStream(fis);
ZipArchiveEntry entry = zis.getNextZipEntry();
while (entry != null) {
System.err.print(entry.getName() + ": " + entry.getSize() + "
(before reading) ");
ZipArchiveEntry next = zis.getNextZipEntry();
System.err.println(entry.getSize() + " (after reading)");
entry = next;
}
{code}
will show the correct size in the (after reading) case. Another reason for the
documentation's advice to prefer ZipFile over ZipArchiveInputStream whenever
possible.
> 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)
