zipfs problems

[Alan Bateman]

Joel Uckelman wrote:
> Hi,
>
> I've been looking at the zipfs demo and have noticed some problems:
>
> * The HashSet ZipFileSystem.closeableObjects could be modified from two
>   different threads if each thread calls ZipFilePath.newInputStream() or
>   newByteChannel() at about the same time.
>
> * Closeables are only removed from ZipFileSystem.closeableObjects when
>   the ZipFileSystem is closed. This means that closed streams and channels
>   will stick around long after they could otherwise be gc'd.
>
> * ZipFileSystemProvider.fileSystems has concurrency problems similar to
>   ZipFileSystem.closeableObjects.
>   
You are right and there are concurrency issues here. Also all returned 
closeables should be wrapped so that close method removes them from the 
set.  Rajendra, do you have cycles to fix this?

(Joel - as background, the zip provider is a demo provider that was 
developed to exercise/test the provider mechanism. It needs a bit of 
work to turn it into a robust provider)

> * Should ZipFileSystemProvider.newFileSystem() really return two distinct
>   FileSystem objects when called with two different env Maps?
>   
I don't see a problem here as the newFileSystem methods are required to 
return a new file system (irrespective of the entries in the map). Note 
that it's okay for several FileSystem instances to share access to the 
underlying zip file and this can be transparent to the user of the API.

-Alan.