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

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: tech-kern@netbsd.org
Subject: Re: lib/30664: realpath and magic symlinks
Date: Fri, 8 Jul 2005 13:38:26 -0400

 On Jul 8,  5:24pm, chuq@chuq.com (Chuck Silvers) wrote:
 -- Subject: Re: lib/30664: realpath and magic symlinks
 
 |  > Perhaps readlink(2) should translate the magic symlink?  But that  
 |  > would break ls(1).  Perhaps we could add a readlink2(2) that takes a  
 |  > flags argument, allowing us to specify "raw" or "translated".   
 |  > readlink(2) would default to "translated", and ls(1) would be changed  
 |  > to use "raw".
 |  
 |  I think that the real problem is having the path interpretation be 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" provides.
 |  
 |  then readlink() would be fine as it is.
 
 I totally agree with that. For now the best course of action is:
 
 1. Leave magiclinks in, default off; mark it experimental and don't pull it
    up to 3.1
 2. Create sysctl to turn on/off readlink() return behavior. This sysctl
    "proc.pid.magiclinks" (or something) defaults to 0, and is inherited
    across fork and exec. If proc.pid.magiclinks==0, readlink returns the
    translated path; if ==1 then it returns the raw path.
 3. In the long term, move the whole mess to namei(), deprecate magiclinks.
    and rename the magiclinks mount option magicnames.
 
 christos