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