Xref: utzoo comp.unix.wizards:15379 comp.databases:2266 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!psuvax1!flee From: flee@shire.cs.psu.edu (Felix Lee) Newsgroups: comp.unix.wizards,comp.databases Subject: Re: getcwd() and friends. Message-ID: Date: 5 Apr 89 02:30:10 GMT References: <3675@ficc.uu.net> <14689@rpp386.Dallas.TX.US> Sender: news@psuvax1.cs.psu.edu Organization: Penn State University Computer Science Lines: 26 In article <3675@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) 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. All the info >that UNIX needs for the chdir is available via the fd. This would open up holes with chroot(), but anyway... You need another open() mode, O_EXEC, open for execution. Then you could fchdir(), fexecve(), and so forth. With a little work, you could then replace all the standard system calls with library routines that call the corresponding f-function. Then knowledge of path names would be localized to the open() function (making it easier to add file access hooks). flink(), funlink(), and frename() are problematical because you also need descriptors to the directories involved, unless you attach knowledge of name and location to file descriptors. Probably not worth the effort. Now if you want to come up with a more powerful model of data storage that lets you layer Unix filesystem semantics on top of it... (Aside from all that, pushdir()/popdir() routines would be handy.) -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee