zipfs problems

[Joel Uckelman]

Thus spake Alan Bateman:
>
> 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?
>

No, what I've already written (separately from any fs work) is based
on java.util.zip, because I didn't want to write the ZIP code from 
scratch. When an entry is opened for writing, it's copied out to a
temporary file (much like the zipfs implementation does when you
request a SeekableByteChannel). When a modified archive is closed (or
flushed), I use ZipOutputStream to create a new archive, copying the
modified files from their temporary locations and the unmodified files
from the original archive, and finally replace the original archive
with the updated one.

I suppose this could be done more efficiently with some custom code,
as there's no point in uncompressing and then recompressing entries
that weren't modified, but writes happen infrequently enough in VASSAL
(the project where we're using this) that I haven't bothered with it
yet. 

> 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.

I already have code for it in my old implementation which I could
contribute, but see below...
 
> 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.

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.

-- 
J.