file locking questions

[Vince Bonfanti]

I'm working on a virtual file system for Google App Engine
(http://code.google.com/p/gaevfs/) and my current implementation is
based on Apache Commons VFS (http://commons.apache.org/vfs/). I was
very excited to discover the NIO2 project and would like to adapt
GaeVFS to use NIO2 as much as possible, but I have some questions
related to file locking:

 1 ) What, if any, are the expectations related to locking by the file
system when a file is opened for reading and/or writing? Is the file
system expected to do any automatic locking, or is the user expected
to do all locking explicitly? Is this behavior file system dependent?

 2) Why is it that SeekableFileChannel must be cast to FileChannel to
get access to file locking? This implies that support for locking is
optional or file system dependent--is that the intention?

Commons VFS currently enforces that only a single output stream can be
open for writing to a file. It does not implement any restrictions on
the number of open input streams, and allows input streams to be
opened while an output stream is already opened (and vice-versa). It
also does not place any restrictions at all on opening a file for
read/write random access, and does not provide any API for
user-controlled file locking. (This all seems very inadequate).

I thought I read somewhere in the JDK API docs that automatic locking
(or not) is file system dependent; unfortunately, I can't seem to find
that comment anywhere.

If locking behavior is file system dependent, I'm thinking about
implementing a scheme with the following characteristics:

 - automatically support a "one writer, many readers" locking scheme
 - opening a file for writing, either by getting an OutputStream or
SeekableByteChannel with write access, gets an exclusive lock that
blocks all other readers and writers
 - opening a file for reading, either by getting an InputStream or
SeekableByteChannel with read access, gets a shared lock that blocks
any writers but allows other readers
 - setting the "read-only" attribute for a file blocks all writers and
allows all readers without requiring any locks
 - support an "no lock" option when opening a file for read and/or
write access that would allow the user to control locking explicitly

Does this seem like a a reasonable scheme? Or does this violate any
conventions that I should be following (but can't seem to find
documented anywhere)?

Thanks.