Xref: utzoo comp.unix.wizards:15466 comp.databases:2300
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!rochester!kodak!gizzmo!lazlo!galaxia!rayssdb!rayssd!mirror!frog!john
From: john@frog.UUCP (John Woods)
Newsgroups: comp.unix.wizards,comp.databases
Subject: Re: getcwd() and friends.
Message-ID: <1215@frog.UUCP>
Date: 5 Apr 89 22:33:00 GMT
References: <3675@ficc.uu.net> <14689@rpp386.Dallas.TX.US> <811@mtxinu.UUCP>
Followup-To: comp.unix.wizards
Organization: Misanthropes-R-Us
Lines: 35

In article <811@mtxinu.UUCP>, ed@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@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu

			Remainder Khomeini!