RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method

[Martin Buchholz]

On Wed, Sep 4, 2019 at 12:54 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 04/09/2019 08:22, Langer, Christoph wrote:
>
> Hi Lance,
>
>
>
> thanks for your comments. I’ve requested the patches for jdk13u and jdk11u
> then. By default they’d reach the Jan 2020 update release, so they’ll get
> some time to bake in there. Actually, since this patch fixes a regression
> that has been introduced just recently, I could imagine that the fix would
> even be a candidate for the October patches. It looks quite obvious and I
> don’t think that there’s a huge performance risk. But I don’t want to take
> this decision on my own ��
>
> There has been significant churn in the zipfs implementation in recent
> releases. Most of the changes came with regression tests but I'm concerned
> that we still don't have enough tests to be confident changes this code.
> Time stamps and zip64 are two areas where we often get bitten. I think we
> need to figure out how to do interop tests with other zip tools too.
> Improved tests would help with the confidence when changing this code and
> also help when there are requests for back ports.
>

I also tend to be cautious about backports, and I agree that zipfs testing
should have been improved, but  8229887 is a serious regression - creating
corrupted zip files - that should be backported ASAP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190904/f002789d/attachment-0001.html>