RFR JDK-8069211: (zipfs) ZipFileSystem creates corrupted zip if entry output stream gets closed more than once

[Xueming Shen]

On 1/16/15 1:06 PM, Francis Galiegue wrote:
> On Fri, Jan 16, 2015 at 10:00 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> [...]
>> Yes, not only the zipfs.  lots of the streams from the j.u.zip pacakge are
>> not "thread safe". We probably
>> need take a look later. It really does not make lots of sense to share an io
>> stream among multiple threads
>> though.
>>
> However the possibility remains that from a same filesystem, two
> threads can open a stream to the same resource.
>
> Sure, the result is ultimately undefined as to the file contents, but
> the fs does not get corrupted... Note: not tested this scenario yet.
>
That use scenario is fully supported. There will be separate streams and
entries corresponding for the different "open" requirements on the same
resource. The updated bytes + entries will be "updated" back to the
underlying storage with appropriate read/write lock. In this bug, the
size data does not match the underlying bytes of the same "entry". Sure
it would be ideal to spend some cpu time and synchronize the read/
write operation on the same stream, it's always a trade-off. It appears
this might be something we have to do.

-sherman