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

[Xueming Shen]

On 01/21/2015 11:27 AM, Alan Bateman wrote:
> On 20/01/2015 20:13, Xueming Shen wrote:
>> Hi,
>>
>> Here is the webrev that now synchronizes the write and close methods to
>> guarantee we have a correct zip entry even when the output stream is
>> accessed by multiple threads.
>>
>> http://cr.openjdk.java.net/~sherman/8069211
> Having write + close synchronized is probably okay although there will be corner cases where write might hang (NFS or other network connection) and so close will block waiting for it. For the issue at hand then it's okay.
>

The default underlying storage of this kind of output stream is a ByteArrayOutputStream, so it should
not be an issue for this case. In case the ZFS is created with an explicit flag "useTempFile", the temp
file will be created (for the entry) at the same dir as the ZFS's path, so if the zfs is on a NFS, yes, the
writing might hang. But as explained previously, data on this entry will not be updated back into the
ZFS storage until the close() of the stream is invoked, so if the close() hangs when the zfs is getting
closed, the worse scenario is the bytes for that entry will not get synced into the zfs, but the zfs itself
should not hang because of one of its entries hangs

> What about the other Closeables, do they require any work?
>

Probably not.

-Sherman