Re: attempt to re-implement sillyrename for NFS in 2.1.*

Alan Cox (alan@lxorguk.ukuu.org.uk)
Mon, 25 Aug 1997 14:06:19 +0100 (BST)


> The nfs server composes the nfs file handle of the path name and the
> inode number and some other stuff.

Actually the NFS server composes the file handle out of anything it likes
its just a token to us.

> 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.

The NFS system grants access by filehandles and is stateless, ie they
punted the whole mess to the client.

> 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.

Well spotted, welcome to NFS. NFS is extremely simplistic in design. One
thing to remember in all this mess however. NFS isnt a posix compliant
fs by any stretch of the imagination and silly rename is designed to
handle the "create,unlink,use" pattern for a file handle, not general
case deletion of used files. The same is true on other NFS clients

Alan