>
> > 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
Why not simply try to get a new valid file handle from the server if
it throws an "-ESTALE" at us?
Claus