zipfs and write support
Joel Uckelman
uckelman at nomic.net
Wed Jan 27 03:13:25 PST 2010
Thus spake Alan Bateman:
>
> It sounds like you've made good progress. If it extends the existing zip
> provider then I assume it must still be based on java.util.zip, right?
Yes, it is. I'm not terribly interested in rewriting the low-level ZIP
file twiddling stuff myself.
> Have you given any thought to access from others VM or applications?
I don't know of any way to stop other proceses from corrupting the
underlying ZIP file. Do you? I thought file locks were advistory on
many OSes. I'm not familiar with what would need to be done to
coordinate across VMs. Is there a compelling reason to do this? It's
an unusual requirement.
> It's hard to comment on the locking without more information - if there
> a file opened for writing then does it block all other (read) access to
> the "file system"?
Yes, but certain kinds of writes will be nearly instant because they
don't involve writing any data, e.g., deleting files or moving files
which were not originally in the ZIP archive. You could tie up the
whole archive by getting an OutputStream and hanging on onto it. It
would be nicer to have subtree locking instead.
--
J.
More information about the nio-dev
mailing list