zipfs problems

[Alan Bateman]

Joel Uckelman wrote:
> :
> Actually, I've already done it for closeableObjects. The only issue I'm
> wondering aobut is whether to use Collections.synchronizedSet() or to
> build a Set wrapper for a ConcurrentHashMap.
>   
A synchronizedSet should be fine. The other part to the fix is each 
returned InputStream, SeekableByteChannel, DirectoryStream, etc. needs 
its close method to remove the closeable from the set.

> I'll be sending in the contributor agreement when I get to the office 
> tomorrow (I can't print at home), so I'll be happy to start sumitting
> patches then.
>   
Great!

> :
> I'm viewing this with the intention of adding the ability to write ZIP
> archives also. Having multiple FileSystem instances for the same archive
> and doing some writes with each one might lead to trouble. OTOH, maybe
> the place for ensuring that the state of the archive remains consistent
> is ZipFileStore---every FileSystem for the same archive could share one
> ZipFileStore.
>
> It's not clear to me what should happen if someone tries to open multiple
> streams or channels on the same archive entry. With a disk filesystem,
> there's nothing stopping you from opening a FileInputStream and a
> FileOutputStream on the same file at the same time. In some limited cases,
> it might not even be wrong, e.g., if you're reading from and writing to
> non-overlapping parts of a file. Various other pathological things are
> possible...
>
> If you close() a read-write archive, that should cause whatever writing
> was done (by writing to the temporary file cache) to be written back to
> the archive---which could mean that if there are other ZipFileSystem
> instances for the same archive, then the archive will have changed out
> from under them. Whether this is a problem, I'm unsure at present. Maybe
> preventing this should just be the responsibility of the user? Hmm.
>   
The zip provider is read-only because it is based on java.util.zip and 
so don't have support for updating zip/JAR files (it would require 
re-writing the entire zip file). I assume, if you are looking to add 
update support then you're probably basing it on something else - is 
that right?

As regards concurrency, then the simplest approach is opening a zip 
entry for writing requires exclusive access to that entry. That would be 
good start anyway.

Asynchronously closing the FileSystem requires that you have an 
asynchronous close solution for each of the channel, streams, etc. that 
might be open. The required behavior for channel is well defined but not 
so for input/output streams. Closing a FileSystem should not impact 
anything that is accessing the zip/JAR file via another FileSystem 
instance. You'll likely need to use file-locking to coordinate access 
with other entities on the system.

-Alan.