Subject: Re: CVS commit: src/sys/miscfs
To: YAMAMOTO Takashi <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 06/14/2004 10:44:27
Content-Type: text/plain; charset=us-ascii
On Sun, Jun 13, 2004 at 03:16:47AM +0900, YAMAMOTO Takashi wrote:
> [moved from source-changes@]
> > as VOP_RENAME() is not intended to support cross-mount renames; any cal=
> > that ever did that would be an error.
> i'm not sure if or not our VOP i/f is intended to support cross-mount ops.
> (yes, i'm one of confused "future programmers". :-)
It's not supposed to, as I see no way our file system implementations=20
> if it isn't as you say, it's better to remove the checks in
> all filesystem implementations and have the upper layer check it instead.
> removing checks only in layered filesystems confuse
> "future programmers" more badly, IMO.
True. I thought we had the checks in the caller of VOP_RENAME, rather than=
the individual file systems. It would also be more efficient as we have=20
only two calls into VOP_RENAME(), one in the nfs code and one as a result=
of the code handling rename(2) calls. You are right, though, that we=20
should keep this test until such a change is made.
> and, actually, we're currently allowing cross-mount renames in
> some cases and the check is needed (and might be insufficient).
> eg. when you attempt to move files from nullfs to its underlying
Hmmm... You're right. I think we need to add more checks. I think we need=
to make sure all three or four vnodes are all on the same mount point.=20
ufs_rename() makes sure that fvp, tdvp, and tvp (if present) are all on=20
the same fs, and I think the ufs_checkpath() code will catch the case when=
fdvp is on a different mount (as then fvp will be the root of the=20
destination fs). At least I wasn't able to make a rename work with fdvp on=
a different mount.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----