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