commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-282) ZipArchiveInputStream returning entries with size -1.
Date Sun, 25 May 2014 17:49:01 GMT


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.

        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;

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:
>             Project: Commons Compress
>          Issue Type: Bug
>    Affects Versions: 1.8.1
>            Reporter: Sebastian Pawlak
>         Attachments:
> 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

This message was sent by Atlassian JIRA

View raw message