I thought Ken was installing a new file over the original.  The bug
was that the client got neither version.

I'm not very clear on the precise details of AFS semantics.  But it
would seem (ffs semantics probably) that when the file got
overwritten, really the install program unlinked it and replaced it.
So having the process on the client (with an open file) hang on to the
reference seems fine, but it seems the binding to the name should go
away then.  Next, the new library is created, and new attempts to
resolve that name to bits anywhere should get the new bits.

  Coda faithfully uses AFS semantics, not unix semantics, and it is quite
  difficult to present a different view on the filesystem for different
  applications. In any case, the originally running applications should be

The above isn't really a different view of the filesystem.  It's
having an open or mmap resolve to a file object, distinct from a name.
After an unlink, the file should be anonymous.  I realize this may be
hard, but it seems odd that it isn't desired.

Is there a good on-line reference for precisely what AFS semantics
are, and why?  I haven't come across this, but I admit to not looking 


Even if having the file open (mmap'd) is accepted as a good reason for
keeping it, there's something wrong with the not found error.  I
wonder if it can be read with the likes of md5/wc/cat and whether it
is mmap'able.  Ken didn't specific the coda versions and the base os
he is using (thus, I'd guess it's some GNU/Linux variant).


        Greg Troxel <gdt_at_ir.bbn.com>