On Fri, 18 Jul 1997, Brian Bartholomew wrote:
> [Peter wrote:]
> > The 0 inode numbers will slowly disappear. You don't need to worry
> > too much about them I think.
> 
> I am surprised that Coda would ever reveal illegal or incorrect
> filesystem entries to an application.  Applications deserve to lose
> when they don't trap file-related errors.  But giving them illegal and
> nonexistant inode numbers (zero) to work with is unfair.

I think Peter was saying that the inode 0 problem was a bug that should be
going away.  I don't think he's saying it's OK to give application
programs gibberish.

In general and except for bugs, Coda is quite careful to honor its
contract with application programs--bearing in mind, of course, that Coda
semantics are not exactly Unix semantics.  For example, when strongly
connected, close() of a written file doesn't return until the file has
been successfully written back to the server.  If the client is not
strongly connected, then the close() may succeed even though, ultimately,
there might be a problem storing the file because, say, the parent
directory might have been deleted.  In this sort of situation, the Coda
approach is to proceed optimistically and signal errors when they arise:
in particular, you would get an error when you try to reintegrate.

There are areas where Coda/AFS semantics can cause problems: for example,
the number of links to a directory is not necessarily (2 + #
subdirectories).  This confuses GNU find.

Michael