Messages in this thread |  | | From | (Alan Cox) | Subject | Re: NFS Problem in Kernel 2.0.27: inode status not updated | Date | 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.
Alan
|  |