java zipentry getsize returns -1

Question

Java zipEntry.getSize() returns the size of the actual file and some times it returns -1 (though the file size is greater than 0).

Java API document says "Returns the uncompressed size of the entry data, or -1 if not known."

Not sure on what situation it will return -1 i.e. on what situation it will be unknown?

Huai

FWIW if you call getSize after reading the stream for that ZipEntry, then it will return the right size. Weird. – Ruelu

Answer 1

you'll get a return of -1 if that is what is in the ZipFile entry table. This is quite simply just an aspect of the definition of the zip file format.

Postage

I get -1 even after writing the size to the zip table with the size function. – Ellieellinger

I don't follow this. I assume when you say “ZipFile entry table” you mean something that is part of the “.zip” file on disk. I created a zip file and then wrote simple Java code to print each entry's size and name. I wrote this twice, once I read the zip file via the ZipFile class and once I read it via the ZipInputStream class. In both cases, it was the same “.zip” file. When reading via ZipFile, I got the correct uncompressed sizes, whereas when reading via ZipInputStream, I got -1. – Sallie

@Sallie The best I can do in explaining further is point you to the Javadocs API for this: docs.oracle.com/javase/8/docs/api/java/util/zip/… – Postage

Answer 2

Surprisely using ZipFile instead of ZipInputStream for getting the entries makes getSize and getCompressedSize to return the right values.

     ZipFile zipfile = new ZipFile("myFile.zip"); 
     java.util.Enumeration zipEnum = zipfile.entries();
     while (zipEnum.hasMoreElements ()) 
     { 
        ZipEntry entry = (ZipEntry) zipEnum.nextElement(); 
        if (! entry.isDirectory ())
        {
            // entry.getName()
            // entry.getSize ()
            // entry.getCompressedSize ()
         }
     }

trick found at http://vimalathithen.blogspot.de/2006/06/using-zipentrygetsize.html

Reservist

Answer 3

Very interesting. I tried the four combinations:

Zip file creation:

• Using jar
• Using zip

Zip file reading:

• Using ZipFile
• Using ZipInputStream

I got the correct uncompressed sizes in three out of four cases, and -1 in one case:

      | ZipFile | ZipInputStream
  ----+---------+----------------
  jar | correct | -1
  zip | correct | correct

Using the Temurin 21 JDK on macOS.

Sallie

A comment on another question points out that the uncompressed size can be in two places: in a local header before each zip entry, and in the central directory at the end of the zip file. The latter entry is mandatory, the former is optional. When reading via ZipFile, the library can look in the central directory and thus always knows the uncompressed size. When reading via a ZipInputStream, the library only has the local header, and thus the uncompressed size may be unknown. – Sallie

Answer 4

This code will return the correct size of zipEntry:

ZipInputStream( BufferedInputStream( cr.openInputStream(zipUri) ) ).use { srcZipStream ->
        var zipEntry: ZipEntry?
        while (srcZipStream.nextEntry.also { zipEntry = it} != null) {
            srcZipStream.closeEntry()
            allZipEntryList.add(zipEntry!!.name)
            Log.e("wkExtract",zipEntry!!.name+" size= "+zipEntry!!.size+" compressed size= "+zipEntry!!.compressedSize)
        }
}

Jobie