Date: Fri, 7 May 2004 12:53:55 +0200 From: Marc Olzheim <marcolz@stack.nl> To: Tim Robbins <tjr@freebsd.org> Cc: freebsd-current@www.freebsd.org Subject: Re: Unified getcwd() implementation Message-ID: <20040507105355.GA93808@stack.nl> In-Reply-To: <20040507100119.GA15782@cat.robbins.dropbear.id.au> References: <20040507092235.GA61837@stack.nl> <20040507100119.GA15782@cat.robbins.dropbear.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040507105355.GA93808>