On Wed, Dec 11, 2002 at 12:08:21AM -0800, Josie Imlay wrote:
> > > Yes, but people who still think 'NFS' will be even more tempted to
> > > ignore that requirement, and probably either not read, or get confused
> > > by instructions that say 'do not modify any files in the exported fs'.
> 
> I think I missed something here, your saying 'how do we know when a files
> been updated' is this a problem with the way coda does offline files? or
> the client? Because if everything is connected you can just use the kernel
> and be like smb or nfs and it's not a problem.
> 
> (but then I think I'm good at missing things... (the subject. :) )

No, this ended up being a bit more technical discussion about the
guarantees that a server provides to clients and how exporting files
directly from the local tree would make it impossible to provide these
guarantees.

A Coda server cannot be like NFS or SMB, because there is replication
involved. When one replica is known to have version 'foo' of a file, and
someone on that machine makes a modification without going through a
Coda client when do we consider the version of the file to be 'bar'
(i.e. when to notify others).

If we notify at the beginning of the modification, other servers and
clients that fetch a copy would get a version they believe to be 'bar'
before the actual changes are committed. So this is not a good
situation. If however we notify after the modification is done, other
servers and client that fetch a copy would think they have 'foo' even
though the file contents might already be changed.

Whichever way you look at it, we can never allow anyone to have direct
access to a file on the server. It will lead to possible undetected
version conflicts where someone thinks he has version 'foo' but really
has 'bar' (or the other way around). So the only allowable access would
be either through a Coda client, or by using the backup/restore
mechanism. i.e. tar up a directory tree, convert the tarball to a
voldump, and restore this as a new volume on the server.

Jan