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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to