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

Stephen R. van den Berg (
Thu, 2 Jan 1997 08:01:02 +0100

Alan Cox <> wrote:
>> >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.

The kernel knows that. The application does not. That's why, for example,
the open(,,O_CREAT|O_EXCL...) attributes generate such an "amusing" NFS
dialog. The kernel is trying to hide the fact that NFS is not POSIX.

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

Ah... Didn't know that. I'll have to take your word for it.
This makes *flushing* the cache an absolute requirement, even after a
successful link(). Though on most systems, if the link() succeeds,
the linkcount can be silently increased, since I've never seen a system
that supported hardlinks but did 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.

That's not an annoyance of NFS, but more a quality of implementation
issue for the NFS server, I think. There's not really much you can
do about that from the client side, though.

           Stephen R. van den Berg (AKA BuGless).

A sign seen at the local pizza place: "DO NOT CARRY TAKE-OUT BOXES BY HANDLES"