zipfs problems

[Alan Bateman]

Joel Uckelman wrote:
> :
> I don't follow. What is the problem with asynchronously closing streams
> that you're referring to? Is it just that not all streams are thread safe?
>
> I'm a bit hazy on whether locking belongs in an FS implementation at all
> (given the current design). E.g, the default FS doesn't provide any way of
> locking itself, though it happens that you can lock files by getting
> FileLocks from the FileChannels returned by the default FS. For zipfs, the
> Channels aren't FileChannels, so you can't lock ZIP entries. 
>
> On the other hand, if zipfs doesn't provide any kind of locking mechanism,
> then it's going to be hard to use it in a multithreaded app. Maybe what
> I'm moving toward is that Path should have methods for acquiring read and
> write locks.
>   
On one level you'll need to coordinate the re-writing of the zip file 
with other VMs or entities that are accessing that zip file. For 
example, our zip implementation mmaps the central directory on some 
platforms so if one VM re-writes the zip file then it's very possible 
that it will cause access in other VMs to SIGBUS. File locking (via 
FileChannel.lock) might help but I suspect you'll need more - perhaps 
even a shared server to coordinates access.

Within a VM, the provider could coordinate access where you have several 
FileSystem instances representing different file systems on the same zip 
file. For zip entries, the simplest starting point is that write access 
requires exclusive access. Later you could define provider specific 
OpenOptions to support other locking modes.

As regards asynchronous close - always tricky. My point was that 
asynchronous close of streams it not well defined. Without checking, I 
can't say how robust the zip streams are when closed asynchronously but 
you'll likely have bigger fish to fly before you come to this.

-Alan.