Re: NFS Problem in Kernel 2.0.27: inode status not updated

Alan Cox (
Thu, 2 Jan 1997 01:31:02 +0000 (GMT)

> >From the program point of view, I don't even *know* if I'm on top of
> an NFS filesystem. I'm programming in a UNIX/POSIX environment. It
> has a link() command and an st_link attribute. It's the task of the

NFS is not a POSIX environment any more than MSDOS is.

> file, then st_link should increase. If it doesn't increase, it's the kernel
> that is at fault. I don't care what the NFS specs say at this point. The

No nobody is at fault. Your program is assuming Unix semantics, NFS does
not provide Unix semantics. Nor am I arguing its a good idea to gratuitously
ignore the change to provide as close a semantic to POSIX as possible. I'm
all in agreement with keeping the count more unixlike

> If the NFS filesystem in question does not support hardlinks, then the
> kernel must make sure that my application gets back an error when it
> tries to perform a link(). That's all I need. A kernel that returns success
> but doesn't create the hardlink is a bug.

An NFS is entitled to support hardlinking but not keep a link count.

> Exactly. That is *precisely* the reason why, in this application, I always
> create files that have unique names that have not existed "since the beginning
> of the universe".

Neat trick. However I said INODE not name. Many NFS file handles are hashed
device,inode pairs. Thats yet another annoyance with NFS.