Subject: Re: kern/35675 (magiclinks implementation broken)
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Christos Zoulas <christos@zoulas.com>
List: netbsd-bugs
Date: 04/01/2007 20:50:16
On Apr 2,  7:27am, yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
-- Subject: Re: kern/35675 (magiclinks implementation broken)

| > On Feb 18, 11:04am, xtraeme@netbsd.org (xtraeme@netbsd.org) wrote:
| > -- Subject: Re: kern/35675 (magiclinks implementation broken)
| > 
| > | Synopsis: magiclinks implementation broken
| > | 
| > | State-Changed-From-To: open->closed
| > | State-Changed-By: xtraeme@netbsd.org
| > | State-Changed-When: Sun, 18 Feb 2007 11:04:13 +0000
| > | State-Changed-Why:
| > | Nobody thinks it's broken, so close it. I'll re-open
| > | another PR about perusertmp.
| > 
| > I think it is broken. realpath(3) does not work with it, and programs
| > that use readlink to do directory normalization (csh) are broken too.
| 
| are you talking about PR/30705?
| 
| > Ideally realpath should be a system call, readlink should return the
| > expanded path, and there should be another system call to return the
| > unexpanded pathname. This way userland programs will work like before.
| > 
| > christos
| 
| can you explain why realpath should be a system call?

Because it is quite pointless to do string gymnastics in userland
where the kernel has all the code to do this. Our code has been
historically broken:

- we had bugs where we forgot to NUL terminate
- we had bugs where the code was not thread-safe

And still:

- it does not handle magiclinks (your PR 30664)

I am looking for something like solaris' resolvepath(2) which can be
used to implement the rest of realpath(3) in userland.

christos