Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!rutgers!psuvax1!schwartz@shire.cs.psu.edu From: schwartz@shire.cs.psu.edu (Scott Schwartz) Newsgroups: comp.unix.wizards Subject: Re: getcwd() and friends. Message-ID: <4445@psuvax1.cs.psu.edu> Date: 7 Apr 89 05:47:19 GMT References: <3675@ficc.uu.net> <14689@rpp386.Dallas.TX.US> <811@mtxinu.UUCP> <4438@psuvax1.cs.psu.edu> <2001@unisoft.UUCP> Sender: news@psuvax1.cs.psu.edu Reply-To: schwartz@shire.cs.psu.edu (Scott Schwartz) Organization: Pennsylvania State University, Computer Science Lines: 25 In-reply-to: greywolf@unisoft.UUCP (The Grey Wolf) I wrote: # Frankly, I think permitting more system calls to take fd arguments # rather than pathnames would be a big win. It certainly seems more # logical in most cases. In article <2001@unisoft.UUCP>, greywolf@unisoft (The Grey Wolf) writes: >Do you really mean "rather than" as "instead of"? I like the idea of >being able to do either/or, depending on what you wanted to do. I mean, >if they were "instead of", and chmod() were eliminated so that only >fchmod remained, how would you change the mode of a file that was mode >000? You wouldn't be able to O_RDWR or O_EXEC the file/directory and >therefore couldn't gain a valid file descriptor to pass to fchmod(). >I think that the option of f() commands should remain open. Good point. Ideally the "fd" mechanism could completely subsume the "path" mechanism. Realistically, you would probably include the non-fd versions of the all the new syscalls for compatability, and to save a call to open/close in common cases. To answer the fchmod problem we could do a couple things. For one thing, we could introduce O_CHMOD to open for mode changes. The open would succeed iff the opener had permission to do a chmod. In general maybe we want a way to open a file for identification but not necessarily access: O_NAMEI anyone? O_NOP? O well. :-) -- Scott Schwartz