lkml.org 
[lkml]   [1997]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: NFS Problem in Kernel 2.0.27: inode status not updated
Date
> >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


\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.026 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site