cvs commit: src/sys/kern vfs_syscalls.c
Joerg Sonnenberger
joerg at britannica.bec.de
Wed Aug 17 11:35:23 PDT 2005
On Wed, Aug 17, 2005 at 11:15:59AM -0700, Matthew Dillon wrote:
> I'm getting really tired of this argument. REALLY tired. Joerg.
> Are you saying that SuS has that sentence in there precisely because
> of NFS? Because that's completely absurd. If they wanted to have a
> requirement that was due to a particular filesystem, such as NFS,
> they would say it. NFS has plenty of problems, worrying about a
> renaming a hardlink to another version of itself over NFS is not one
> that I really care about.
So we change the semantic of an operation, to unbreak one filesystem. We
break another filesystem with that. We most likely break other
filesystems as well, since any non-DragonFly network filesystem (AFS,
Coda, SMB, NFS) doesn't have such a semantic.
Sure, NFS is a special and broken filesystem. But it is not the only
thing which was broken by this. Even if we can get notified about
namespace changes by the server, we still have an inherent race because
YOU VIOLATED THE OPERATIONAL LAYER. Just from the abstract point of the
VFS layer, it doesn't might sense at all for a specific filesystem to
behave like this. The serialisation point for a remote filesystem must
be the server, otherwise you have to actively lock the namespace and
that is not supported for any of the above mentioned filesystems.
rename(2) must NEVER to remove a file. It is an important criterion,
e.g. maildir depends on it. Anything thing else is *broken*.
Joerg
More information about the Commits
mailing list