Unified getcwd() implementation
Marc Olzheim
marcolz at stack.nl
Fri May 7 03:53:56 PDT 2004
On Fri, May 07, 2004 at 08:01:19PM +1000, Tim Robbins wrote:
> > Hi,
> >
> > (Re: http://lists.freebsd.org/pipermail/freebsd-arch/2003-August/001152.html)
> >
> > > Yes, it's quite an old patch, and much has happened since it was written.
> >
> > Mostly some fine-grained locking was introduced.
> >
> > I hope I got everything covered. Here Bruce's patch reworked, that works
> > for me. (even over NFS ;-))
> >
> > Anyone care to share their view on it ?
>
> Why is this necessary? Emulation of the Linux getcwd() syscall belongs
> in the Linux emulator. There is also some fairly blatantly plagiarised code
> in this patch.
Because getcwd() is a function that might or might not return EACCESS in
the current implementation, depending on whether the current path is in
the cache or not. If in /a/b/c/ directory b is unreadable for a user,
/a/b/c is returned by getcwd() as long as it is in the cache (kernel),
if not, the libc getcwd tries to resolve it, but fails.
Besides from the inconsistency (see standards/44425) it breaks
linux-targeted software that expects getcwd() to always return something
valid. (see bin/22291 kern/39331 kern/55993 kern/30527)
And yes, this is blatantly plagiarised, since most of the code came
straight from compat/linux/linux_getcwd().
Why reinvent the wheel...
Marc
More information about the freebsd-current
mailing list