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