getcwd() and friends.

Scott Schwartz schwartz at shire.cs.psu.edu
Fri Apr 7 15:47:19 AEST 1989


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 at unisoft.UUCP>, greywolf at 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		<schwartz at shire.cs.psu.edu>



More information about the Comp.unix.wizards mailing list