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.redes...@oracle.com> > Sent: Montag, 13. Mai 2019 16:59 > To: Langer, Christoph <christoph.lan...@sap.com>; core-libs-dev <core-libs- > d...@openjdk.java.net>; nio-dev <nio-...@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 > >
