Code review request 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field
Xueming Shen
xueming.shen at oracle.com
Thu Aug 25 18:28:03 UTC 2011
Alan
Webrev has been updated to
(1) use the new try(resource){}
(2) update the existing test case LargetZip to
a) be able to add one more entry at the end of the > 4g zip via
ZipFileSystem
b) read through all entries inside the large zipfile, given
zipfile's self-crc-check
it guarantees the correctness of the zipfile. So it now goes
through 18G+
file read/write for one round:-)
(you have to use -XX:-UseLoopPredicate on server vm for now to
workaround
the C2 loop redicate bug)
http://cr.openjdk.java.net/~sherman/7077769/webrev/
-Sherman
On 08/24/2011 12:06 AM, Alan Bateman wrote:
> Xueming Shen wrote:
>> :
>>
>> Fix has been verified/test manually with existing test cases. Given
>> the nature
>> of the > 4G zip data file. I'm not including an auto regression test.
>>
>> Webrev is at
>>
>> http://cr.openjdk.java.net/~sherman/7077769/webrev
> The zip64 fix looks okay to me. The fix to sync() is okay too although
> I would change this to use try-with-resources.
>
> On the test, I agree an automated test might be too slow to run.
> However, as zip64 is tricky to get right then having a sanity test in
> the test tree (without a @test tag) would be useful.
>
> -Alan
More information about the core-libs-dev
mailing list