Re: Unified getcwd() implementation

From: Marc Olzheim <marcolz_at_stack.nl>
Date: Fri, 7 May 2004 12:53:55 +0200
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
Received on Fri May 07 2004 - 01:53:56 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:53 UTC