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

[Xueming Shen]

On 1/16/15 1:19 PM, Xueming Shen wrote:
> 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
Btw, this "update" happens when the stream is "closed". At the background,
all zip entries are managed under a LinkedHashMap; The later closed stream
takes the position, the earlier one gets thrown away.

-sherman


> 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