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