Subject: Re: lib/30664: realpath and magic symlinks
To: None <,,>
From: Bill Studenmund <>
List: netbsd-bugs
Date: 07/08/2005 23:58:01
The following reply was made to PR lib/30664; it has been noted by GNATS.

From: Bill Studenmund <>
To: Jason Thorpe <>
Cc: Chuck Silvers <>,
	YAMAMOTO Takashi <>,,,
	NetBSD Kernel Technical Discussion List <>
Subject: Re: lib/30664: realpath and magic symlinks
Date: Fri, 8 Jul 2005 16:57:25 -0700

 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 On Fri, Jul 08, 2005 at 10:35:29AM -0700, Jason Thorpe wrote:
 > On Jul 8, 2005, at 10:23 AM, Chuck Silvers wrote:
 > >I think that the real problem is having the path interpretation be =20
 > >different
 > >for symlinks vs. other path lookups done in the kernel.  it would make
 > >a lot more sense to have the tranlation done for all pathname lookups
 > >or none, and not this awkward halfway thing that "magic symlinks" =20
 > >provides.
 > >
 > >then readlink() would be fine as it is.
 > So, the question is:
 > Are these magic names interpreted by lookup() before handing them off =20
 > to VFS_LOOKUP()?  I would guess it would have to be, otherwise it =20
 > would just be insane.
 My thought is to keep the processing in namei(). Just change it so that=20
 rather than looking at a path passed from a symlink (i.e. after lookup()=20
 returns), we look at all paths before we call lookup().
 I realize that this change would require magicname handling to be=20
 system-wide rather than per-mountpoint. I think that's fine. After all,=20
 the semantics are system-wide.
 Take care,
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 Version: GnuPG v1.2.3 (NetBSD)