Re: attempt to re-implement sillyrename for NFS in 2.1.*
Claus-Justus Heine (Heine@physik.rwth-aachen.de)
25 Aug 1997 02:59:50 +0200
> Therefore, there will always be problems: the inode on the client will
> always contain the last updated nfs file handle for it. But if one
> occurance of a multiply linked file is unlinked, this might be the
> path that corresponds to the nfs remote file handle, and therefore the
> server responds with an -ESTALE error.
>
> MMh. I haven't read any NFS specs yet, but looking at the
> implementation of the new kernel level nfsd and the old user level
> nfsd I suspect that the nfs server grants access to file names, not to
> inodes. I don't know anything of the requirements. Somewhere I had
> found the nfs3 specs on ftp.funet.fi, didn't read them yet.
>
> IMHO: I can't tell whether the nfs server implementation is buggy or
> the NFS client implementation is buggy, but they cannot go together
> w.r.t. multiply linked files. It just CANNOT work this way.
At least the nfsv3 spec state the access to a file by a nfs file
handle can be revoked by the server at any time, and that the server
has to return and -ESTALE error in this case. Doesn't that mean that
the NFS client code should be changed in such a way that it silently
tries to re-get (i.e. re-lookup) the nfs file handle in case an
-ESTALE error is returned?
Well. The above means that the behavior of the server is maybe
inconvenient, but not buggy.
And that the current client implementation seems to have some
problems.
Cheers
Claus