Messages in this thread |  | | Date | Thu, 2 Jan 1997 08:01:02 +0100 | From | (Stephen R. van den Berg) | Subject | Re: NFS Problem in Kernel 2.0.27: inode status not updated |
| |
Alan Cox <alan@lxorguk.ukuu.org.uk> 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. -- Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
A sign seen at the local pizza place: "DO NOT CARRY TAKE-OUT BOXES BY HANDLES"
|  |