JDK7's java.util.zip breakage with very large files

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