Talking more with Eli we did find out what had happened (not yet why or
how): on the server the _file_ had been removed, but not the directory
entry or vnode.   

Generally speaking there is a sensitive area here in the server: it has a
full transaction system for meta data, but NOT for files.  So it is
possible for files to get out of sync with RVM (metadata) and the salvager
is supposed to correct that (salvager is pretty much "fsck for Coda").

The server recognizes such vnodes as "barren" and will create an empty
file for them if it is started with the -debarrenize flag.  

I'm currently working on the salvager which does this and this seems a
good candidate to become a default flag.

Of course what Jan says here is also very important, but I'm not sure
exactly how it relates to what happened to Eli. 

- Peter -

On Fri, 1 May 1998, J.A. Harkes wrote:

> 
> "Peter J. Braam" wrote:
> > It's pretty clear that it is a bug in the kernel code and to be more
> > precise the cache entry in the dcache doesn't get invalidated apparently. 
> > 
> > Did you mount volumes or anything like it?  This could well be at the root
> > of the confusion.
> > 
> > Peter
> 
> I have seen exactly these problems when reintegration records were lost,
> and the file `existed' in the client's metadata, but not on the server.
> 
> But it might also have been fixed/avoided by correcting the size of the
> CFS_FLUSH downcall, which was ignored as the packet size was too small.
> 
> Jan
>