>
> > Why not simply try to get a new valid file handle from the server if
> > it throws an "-ESTALE" at us?
>
> Because if the file has been deleted you will get an error trying to get
> a new handle. NFS is _stateless_ (ish) so if you delete a file the server
> doesnt have a clue that a file has been deleted while in use.
Yesno. You're still talking about "silly rename". I'm talking about
the cases when then server alters the file handle after renaming the
file, moving it to another directory. In this case the client (who has
initiated the renaming of the file) knows the new name and can do a
new lookup with the new name and get a new valid file handle. Also, if
you have a multiply linked file, then the file handle that the client
is using might become invalid when unlinking one occurance of that
file. Also in this case we could do a nfs lookup with the other
pathnames that haven't been unlinked yet.
And the nfs spec also states that the nfs server can drop the nfs file
handle whenever it likes to do so. In this case we can simply re-get a
valid file handle by doing a lookup with the name of the file that
endures the -ESTALE error.
Clearly: doing a lookup with a name that has been deleted on the
server will and has to fail. But when having renamed a file we have
the new path name on the client. And when unlinking one instance of an
inode we still may have (we do have) path name information (dentries)
that refer to that inode with a path name that is valid on the server
side and therefore can be used for nfs lookups.
I'm not talking about lookups with path names that don't exist any
longer on the server. I know very well that an nfs_proc_unlink()
really destroys the file. And an nfs_proc_rename() doesn't leave a
trace of the old instance of the file.
Well, hope that I have expressed myself more clearly this time. I
think we were talking about different things.
Cheers
Claus