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