RFR(S): 8223597: jdk/nio/zipfs/ZipFSTester.java RuntimeException: CHECK_FAILED! (getAttribute.crc <entries20> failed 6af4413c vs 0 ...)

[Langer, Christoph]

Hi Claes,

thanks for reviewing.

Yes, seems csize will always be > 0 if the entry got deflated. I don’t know the details of the zip algorithm, but DeflaterOutputStream::finish() always causes 2 bytes to be written when the buffer for the file/channel has 0 bytes. So I think the fix really is correct.

Best regards
Christoph

> -----Original Message-----
> From: Claes Redestad <claes.redestad at oracle.com>
> Sent: Montag, 13. Mai 2019 16:59
> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; nio-dev <nio-dev at openjdk.java.net>
> Subject: Re: RFR(S): 8223597: jdk/nio/zipfs/ZipFSTester.java
> RuntimeException: CHECK_FAILED! (getAttribute.crc <entries20> failed
> 6af4413c vs 0 ...)
> 
> Changes and new tests looks good,
> 
> will csize always be > 0 for an empty file/channel?
> 
> /Claes
> 
> On 2019-05-13 14:14, Langer, Christoph wrote:
> > Hi,
> >
> > please review this fix of a regression in zipfs after JDK-8222532 [0].
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8223597
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223597.0/
> >
> > The issue occurs when an empty file/channel is persisted into a zip file. The
> entry had already been compressed with CRC of 0 at the time the output
> stream to the zipfs was closed. But when the Entry is eventually synced to
> the zip file, this is not detected and the bytes get compressed again.
> >
> > The test was adapted to reliably provoke this intermittent error. In the test
> I also suppressed printout of an expected Exception to avoid some
> distraction when reading its JTR files.
> >
> > Thanks
> > Christoph
> >
> > [0] https://bugs.openjdk.java.net/browse/JDK-8222532
> >