Email list hosting service & mailing list manager

File mode: char/block special files and permission bits Göran Weinholt (31 Jul 2019 14:25 UTC)
Re: File mode: char/block special files and permission bits hga@xxxxxx (31 Jul 2019 15:03 UTC)
Re: File mode: char/block special files and permission bits Lassi Kortela (31 Jul 2019 15:32 UTC)

Re: File mode: char/block special files and permission bits hga@xxxxxx 31 Jul 2019 15:03 UTC

That turns out to be a problem in the description, where I say
"Returns ... mode (permission bits).... " I should either add
something before the close paren, or drop the parenthetical comment.

Except for that error, the SRFI, and the Chibi Scheme implementation
of it return all the bits, which are necessary for the following
file-info-directory?, file-info-fifo? etc. predicates, no masking is
intended to be specified in the SRFI.

Thanks for bringing this to our attention.

- Harold

----- Original message -----
From: "Göran Weinholt" <xxxxxx@weinholt.se>
Date: Wednesday, July 31, 2019 9:25 AM

Hello schemers,

The file-info records in the proposed SRFI 170 do not fully correspond
to the stat structure in POSIX. The current proposal does not provide
the full st_mode field. Only the permission bits are kept, but the
st_mode field originally contains more information.

This matches Scsh, but Scsh also provides a type field. The current
proposal has no file-info:type field, so we lose some information. In
particular, the distinction between block and character special devices
is lost.

POSIX says "The file permission bits are defined to be those
corresponding to the bitwise-inclusive OR of S_IRWXU, S_IRWXG, and
S_IRWXO". If this is the mask used for file-info:mode, then we also lose
the setuid, setgid and sticky bits (and any implementation-defined
bits).

What's the harm in letting file-info:mode return st_mode unmasked?

Regards,

--
Göran Weinholt
https://weinholt.se/