>
> > 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.
>
> Suppose another client has renamed two files. You've now broken that
> behaviour and written to the wrong file. A failure seems preferable to
> suprise writes to other files
Mmmh. You mean: it has renamed "foo" to "fii" and some other files,
say "X", to "foo" in which case my hack would then obtain a new file
handle for "foo". Which is indeed a bad idea. Sad. Very sad.
Okay. So we have to live with the shortcomings of NFS. But what about
Olaf's proposal:
/*
* RENAME
* FIXME: Some nfsds, like the Linux user space nfsd, may generate a
* different file handle for the same inode after a rename (e.g. when
* moving to a different directory). A fail-safe method to do so would
* be to look up old_dir/old_name, create a link to new_dir/new_name and
* rename the old file using the silly_rename stuff. This way, the original
* file in old_dir will go away when the last process iput()s the inode.
*/
MMh. Guess it would at least compensate for the "rename to another
directory" at the price of extra hard links. Although one would not
have any gurarantee that is works. In fact NFS even doesn't guarantee
that the file handle stays valid even when none of the NFS clients
asked the server to do anyting, nor some local manipulations on the
server have been performed. It is just totally arbitrary!
Get the file handle and pray!
Cheers
Claus