Subject: RE: RENAME

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 22 Sep 1999 11:42:15 -0700

> I would like to add a mechanism that would inform clients that
> filehandles go stale after a rename.
> 
> The client could then update any openfiles that it renamed with:
> 
>     PUTFH  (source dir)
> 	RENAME "a" (dest dir) "b"
> 	SAVEFH
> 	PUTFH  (dest dir)
> 	LOOKUPFH "b" ("a"'s filehandle)	 # a new operation
> 	GETFH
> 	RESTOREFH

What exactly does LOOKUPFH do?  How does it differ from LOOKUP?

> 
> Then we could get rid of this paragraph:
> 
> 	A file handle may or may not become stale on a rename.  However,
> 	server implementors are strongly encouraged to attempt 
> to keep file
> 	handles from becoming stale in this fashion.
 
You would still have the problem of file handles going stale
because another client did the rename, so you it would still be
better to keep your handles fresh on rename, although maybe
you could get rid of "strongly".

---

From: "G. Allen Morris III" <[email-masked]>
Date: Wed, 22 Sep 1999 14:47:53 -0700

>>>"Noveck, Dave" said:

LOOKUPFH is the same as LOOKUP except that it take two argumnets:
the names and a filehandle.  After a successful lookup the server
compares the new current filehandle with the filehandle given as
an argument.  It returns errors if the filehandles are different
or if it can't tell if they are the same.

 > you could get rid of "strongly".

Quite right --  it's always something. 

One approach to help solve this would be to have an EXPIRE
try list of recovery meathods.

It would do the following:

first:
       PUTFH   (filehandle) # gives EXPIRE
	   GETFH                # if OK store in cache your done
second:
	   PUTFH (current dir filehandle)
	   LOOKUPFH name, (filehandle)
	   GETFH
third:
	   PUTROOT
	   LOOKUPFH (full path), (filehandle)
	   GETFH

The first case would handle the case where a file was renamed on
a different client.  (If the client does not do a PUTFH on the file
handle before the server flushes the cache it will loose, but it is
something.)

The second case is where the server can access directories but not
files.  This is the common case.  On MSDOS the problem is that the
attributes for a file are stored in the directory entry so you have
to be able to access the directory before you access the file.

The third case is a punt and will work as long as none of the
elements of the path have changed.  And since the server can
hide some meta information in the filehandle of the LOOKUPFH
it might even beable to recover from an in-directory rename.

--------------------------------
       G. Allen Morris III