JDK7's java.util.zip breakage with very large files (original) (raw)

Alexander Sack pisymbol at gmail.com
Thu Feb 7 20:33:47 UTC 2013

On Thu, Feb 7, 2013 at 3:23 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

There is difference between doing

"jar xvf data.jar data" and "jar xvf data.jar" If the previous one works, it means the zip file should have the healthy end table there (it goes down to end->cen-> loc->data file).

$ jar xvf data.jar data java.util.zip.ZipException: ZIP_Read: specified offset out of range at java.util.zip.ZipFile.read(Native Method) at java.util.zip.ZipFile.access$1200(ZipFile.java:46) at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:464) at java.util.zip.ZipFile$1.fill(ZipFile.java:247) at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158) at java.io.FilterInputStream.read(FilterInputStream.java:107) at sun.tools.jar.Main.copy(Main.java:771) at sun.tools.jar.Main.copy(Main.java:803) at sun.tools.jar.Main.extractFile(Main.java:951) at sun.tools.jar.Main.extract(Main.java:905) at sun.tools.jar.Main.run(Main.java:254) at sun.tools.jar.Main.main(Main.java:1167)

The later goes from the sequential looking up from the beginning, so it only looks into the "loc" table, it may extract the file out even there is no cen and end tables.

I thought you just did "java xvf data.jar" in your previous email.

I did. That works. md5sum's match original data file.

-aps

More information about the core-libs-dev mailing list