From owner-freebsd-current Fri Sep 7 11:38: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id A48CD37B401; Fri, 7 Sep 2001 11:37:59 -0700 (PDT) Received: from mindspring.com (dialup-209.247.142.57.Dial1.SanJose1.Level3.net [209.247.142.57]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA26794; Fri, 7 Sep 2001 11:37:56 -0700 (PDT) Message-ID: <3B991430.43F5BECE@mindspring.com> Date: Fri, 07 Sep 2001 11:38:40 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: "John W. De Boskey" , Current List Subject: Re: __getcwd & errno 20 (Not a directory) vfs_cache.c References: <20010907065306.9AF8D380C@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > > The really annoying aspect to this is that it doesn't > > happen everytime, and happens more often when in a nfs > > mounted directory vs. a local directory. > > Yes, this is expected due to __getcwd(2) being incomplete. > > NFS expires the directory nodes after about 10 minutes. This stops > __getcwd() working, and stops things like /proc/*/file from working. (just > try executing /usr/local/bin/something where /usr/local is NFS mounted, and > wait for ~10 minutes.. /proc/pid/file will switch to: > lr-xr-xr-x 1 test users 7 Sep 6 23:51 /proc/521/file@ -> unknown Implementing "getcwd" as a system call is a stupid idea; I believe the only reason FreeBSD has this is that Linux had it first. A canonically correct answer would be to return "." in all cases, anyway, since it would allow current-directory relative programs to work. The only programs which would suffer are: o Programs which are too stupid to remember that they called "chdir", but want to cache the cwd so that the next time they are run, they can call "chdir" again (and forget again). o Programs which print out the current working directory as eye candy for the user. Remember that there are file systems which permit hard links on directories, and then "forget" the down path, for which the both of these uses will inevitably break, anyway. Even the existance of a "getcwd(3)" (as opposed to a "getcwd(2)") begs for these to break on the assumption that such links will either be "remembered" following traversal, or will all have equivalent permissions. It's really, really stupid to assume that "all the world's an EXT2FS", or "all the world's a post 1994 BSD FFS"... and this is nowhere _more_ true than when doing things like an NFS mount of a completely alien FS. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message