getcwd() and friends.

[John Woods]

In article <811 at mtxinu.UUCP>, ed at mtxinu.COM (Ed Gould) writes:
>>>One thing that really would make things a lot easier would be a fchdir()
>>>call, that took a file descriptor and tried to chdir to it.
>>However ... all of the information needed for a chdir() is not present
>>in the file descriptor.  It is possible to be handed a file descriptor
>>which you would not be able to have opened because some component of
>>the search path denies access now, but at some point in the past did
>>allow access.

This objection had occurred to me also, but isn't necessarily SO bad, since
changing access permissions on directories doesn't cause you to lose your
current working directory.

> Worse than that, the permission required to open a directory is "r"
> (since one may not open a directory for writing), whereas the
> permission required to change to one is "x".

This one is a killer.

Perhaps a better model might be a pushd()/popd() arrangement (perhaps 
even with a swapd()).  A stack depth of 2 is enough to make it useful
for getcwd().  You lose the ability to necessarily shut a process out
of a directory if it happens to lose it, but that doesn't seem too much
a loss; you don't lose the distinction between r and x access modes.
A stack depth greater than two seems to be to start on a "slippery-slope"
problem; the more you allow, the more resources a badly written process
can take up, but the more uses it can have (though to use it for a shell
directory stack, you would want an arbitrary (or at least very large) limit,
which is clearly unacceptable).

-- 
John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101
...!decvax!frog!john, john at frog.UUCP, ...!mit-eddie!jfw, jfw at eddie.mit.edu

			Remainder Khomeini!