The following reply was made to PR lib/30664; it has been noted by GNATS.

From: Bill Studenmund <wrstuden@netbsd.org>
To: Jason Thorpe <thorpej@shagadelic.org>
Cc: Chuck Silvers <chuq@chuq.com>,
	YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, netbsd-bugs@netbsd.org,
	gnats-bugs@netbsd.org,
	NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
Subject: Re: lib/30664: realpath and magic symlinks
Date: Fri, 8 Jul 2005 16:57:25 -0700

 --LZvS9be/3tNcYl/X
 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:
 >=20
 > On Jul 8, 2005, at 10:23 AM, Chuck Silvers wrote:
 >=20
 > >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.
 >=20
 > So, the question is:
 >=20
 > 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,
 
 Bill
 
 --LZvS9be/3tNcYl/X
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.3 (NetBSD)
 
 iD8DBQFCzxLlWz+3JHUci9cRAsiNAJ9CmD7rWBqibBXvblDz5R4APeWrBgCfS04s
 UzUq8Ofu98km8cCbsONjo/M=
 =TuO3
 -----END PGP SIGNATURE-----
 
 --LZvS9be/3tNcYl/X--