RFR JDK-8069211: (zipfs) ZipFileSystem creates corrupted zip if entry output stream gets closed more than once
Xueming Shen
xueming.shen at oracle.com
Sat Jan 17 19:50:20 UTC 2015
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
More information about the nio-dev
mailing list