zipfs problems

Joel Uckelman uckelman at
Mon Oct 19 13:25:08 PDT 2009

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

I'm not so interested in locking ZIP entries outside of a single VM. If
other processes are trying to read or write to a ZIP archive while we're
using it and this is expected behavior rather than a screw-up, then we're
way beyond the usual use case anyway.

> 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.
Ah! That's what I was looking for. This should be done with OpenOptions.


More information about the nio-dev mailing list