Martin Ginkel <martin_ginkel_at_web.de> writes:

> Can someone explain, what condition triggers venus to start writing
> back the file (Why?),
> which calls have to happen: fopen("file","w"); close(), is a write()
> necessary. And when does this happen (the close() call?).

Coda semantics differ from what you might expect from a
traditional FFS filesystem.

In particular, in coda the following operations:

   open file RW
   read a bunch of stuff
   close file

will cause venus to

   contact the server to acquire a write lock, thereby revoking read
   leases from others (at open time)

   (not do anything on the net during read)

   execute a store operation back to the server (which goes in CML and
   then reintegration happens in the post-no-connected world) on close

I view some of this as a bug, but it's not trivial to fix.

bug #1: if you don't actually write, the file should not be modified.
FFS doesn't update the mtime if you don't actually write - open for
write is "may I write", not actually writing.  Coda's worldview is
that it's not a bug to be different from FFS (acls, etc.), and that's
fine, but I think that if instead of Store venus just returned the
write lock to the server with a "done now; I didn't actually write"
that it would be more useful behavior.


The truly hard part is that it would be nice to not have to get an
exclusive lock on opening for rw, but only on first write, so others
don't have their read locks revoked.  But, that means open for rw can
succeed and then write fail, and that can't happen now (unless a
conflict happens?).

I realize now that I may be engaging in connected-mode oldthink about
the locking, so perhaps Jan can comment about whether the pretty good
consistency guarantees for connected mode are simply gone.

Still, I think it would be useful to keep a 'actually written' flag on
open-for-write files and avoid the Store operation.

I found out about this because cfs (cryptographic filesystem) by
default opens ciphertext files rw even when the plaintext is opened
readonly.