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