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

[Xueming Shen]

On 1/16/15 11:36 PM, Alan Bateman wrote:
> On 16/01/2015 21:00, Xueming Shen 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.
> I wasn't suggesting it would be make sense to have multiple threads 
> writing to the same output stream, rather it's the async close of the 
> FileSystem that I was wondering about as this should really 
> synchronize with any readers/writers to allow all open resources to be 
> closed before closing the FileSystem.
>
> -Alan

Zipfs should be fine in this "async close" scenario. We don't explicitly 
close any open
output streams in zipfs.close(), because any open output stream actually 
doesn't have
direct reference/link with the underlying node/entry tree storage. The 
entry and its
content will only be synced into the storage tree via

     outputstream.close()->zipfs.update(Entry e)

and zipfs.update() and zipfs.close()->zipfs.sync ()  is under the 
begin/endWrite() lock.
Which means if the output stream is closed before the sync(), everything 
will be in,
if after sync() everything is out.

In case of input streams, zipfs.close() does try to close any open input 
stream stored
in "streams",  mainly because each stream does hold a local reference to 
the underlying
"channel" to the underlying zip file, explicitly close those input 
streams in zipfs.close()
prevents future reading to the channel.  We do have sync and async 
mechanism (the
ExChannelCloser) to help the scenario of have outstanding open input 
stream when
zipfs is getting closed.

The logic should work, but can't guarantee bug-free though:-)

-Sherman