Coda File System

Re: more weirdness with my weakly connected client

From: <>
Date: Thu, 09 Jul 1998 18:16:42 -0300
> I was sitting in my dir and I just remade the project I was working on and 
> fixed a few compilation errors. Then venus decided to reintegrate and all
> of the sudden the dir that I was in disappeared out from under me.

I believe that this is unrelated to the patch, venus allocates a temporary 
file-identifier when creating things disconnected, and replaces it for the 
real one when reintegrating. However, a fid is directly related to the files 
inode number and thus your directory got `pulled' from under you. What might 
work is
doing a `cd' from the fs-root to the directory you were in.
> Kind of interesting huh?

Well, let's call it a feature then.

> [bwoodard_at_trill WorkArea]$ ls
> ls: npadmin: Input/output error
> CVSROOT/      ciscolplib/   mkfile.c      scripts/      utils/
> a.out*        hpmclisten/   mkfile.c~     sddb/         webadmin/
> balsvr/       jdxfer/       mkprint/      sddbtcp/
> bob           lpr-secure/   npadmin-0.3/  sockxfer/
> bootp/        lprxfer/      pjlf/         sudoers
> cgi-scripts/  mkfile*       pradmin/      upderp/
> [bwoodard_at_trill WorkArea]$ mkdir npadmin
> mkdir: cannot make directory `npadmin': File exists
> [bwoodard_at_trill WorkArea]$                            
> It seems like it exists but it isn't visible.

Yes, I hate it when venus does that. I had situations where I could see a file 
with ls, but not with ls -l. The file exists, and the `venus-cached' directory 
list is not up-to-date, which it should detect, but doesn't.

One way of fixing this (when you have a second client), is create a file in 
the same directory on the other client. This triggers a server-callback to 
this client, which will refetch the directory contents.
Another way is `cfs flushobject' for your `WorkArea' directory.

Received on 1998-07-09 18:18:37