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
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
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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message