>>     - Regarding set-file-mode, set-file-owner and set-file-group: Scsh
>>     allows the first argument to be fname, fdes or port.  Does
>>     srfi-170 restrict it to just a file name?
>
>     We tried to be */extremely/* specific and correct about argument
>     specifications.  These says fname/file name, so that's it.  It would
>     of course be easy in both the SRFI document and the Chibi Scheme
>     sample implementation to add port and/or fdes.  As I remember, we
>     discussed their proper scope, at least in the context of going over
>     every file manipulation procedure and deciding which should have
>     which possible argument types.  Can't remember why these 3 were
>     limited to file names.
>
> The spec can be extended later in the backward compatible way, so it is
> less problematic.  Still, file-info accepts fname/port, so it's a bit weird.

fchmod() fchown() are in POSIX so accepting fd's and ports would be useful.

>>     - I wonder why set-file-owner and set-file-group are separate
>>     calls, while the underlying POSIX call is one.  It may be for
>>     compatibility, but will there be a case that you want to change
>>     both owner and group atomically?  (I assume it rarely matters, but
>>     still, why not expose the POSIX feature?)
>
>     It would be easy to turn these into one procedure by faking
>     something like what's in POSIX for setting timespecs for files, have
>     a special argument that says don't change "this" argument, owner or
>     group.  More complicated to understand, though ... but the POSIX
>     command line chown /does/ allow setting both owner and group at the
>     same time, by allowing the latter to be an optional argument.  Would
>     the latter be OK?  And for either, what should the single procedure
>     be named?  (We'll easily spend more time discussing that than making
>     the changes :-).
>
> Yeah, it can easily be a bikeshed.
> Personally, I think splitting POSIX chown(2) to two APIs is an arbitrary
> choice with unnecessary restriction (losing the ability to change owner
> and group atomically), so it's a wart I hope to be corrected in this
> opportunity.  I'm totally fine with the name (set-file-owner fname uid
> [gid]), for the underlying POSIX call is "chown".  If we prefer totally
> descriptive name, (set-file-owner/group fname uid gid) or
> (set-file-owner&group fname uid gid).  It is POSIX interface, so I
> believe aligning interface to POSIX semantics is *less* complicated than
> introducing arbitrary new interface.

These are good points, but it's worth remembering that the division in
the syscalls themselves is a bit arbitrary. E.g. chmod(), chown() and
utimes() are all different syscalls so race conditions can still happen
when they are used in sequence. A unified setfileinfo() syscall would
avoid those races, but how would kernel programmers later extend the
info struct?

Races could perhaps be solved using file locking, but proper file
locking in Unix is famously difficult, and is probably slow if changing
the metadata for lots of files at once.