Email list hosting service & mailing list manager

Review of SRFI 170 through 3.2 I/O hga@xxxxxx (22 Apr 2020 17:13 UTC)
Re: Review of SRFI 170 through 3.2 I/O John Cowan (22 Apr 2020 20:42 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (22 Apr 2020 20:53 UTC)
Re: Review of SRFI 170 through 3.2 I/O John Cowan (22 Apr 2020 21:29 UTC)
Re: Review of SRFI 170 through 3.2 I/O hga@xxxxxx (22 Apr 2020 23:57 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (22 Apr 2020 21:36 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (22 Apr 2020 21:42 UTC)
Re: Review of SRFI 170 through 3.2 I/O John Cowan (23 Apr 2020 03:37 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (23 Apr 2020 07:02 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (23 Apr 2020 07:05 UTC)
Re: Review of SRFI 170 through 3.2 I/O Göran Weinholt (23 Apr 2020 10:53 UTC)
Re: Review of SRFI 170 through 3.2 I/O Marc Feeley (23 Apr 2020 11:09 UTC)
Per-thread umask Lassi Kortela (23 Apr 2020 11:30 UTC)
Re: Per-thread umask Marc Feeley (23 Apr 2020 11:43 UTC)
Re: Per-thread umask Lassi Kortela (23 Apr 2020 11:47 UTC)
Re: Per-thread umask Marc Feeley (23 Apr 2020 11:59 UTC)
Re: Per-thread umask John Cowan (23 Apr 2020 15:03 UTC)
Re: Per-thread umask Marc Feeley (23 Apr 2020 15:20 UTC)
Re: Per-thread umask Lassi Kortela (23 Apr 2020 16:02 UTC)
Re: Per-thread umask John Cowan (23 Apr 2020 16:03 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (23 Apr 2020 11:14 UTC)
current directory and openat() et al Lassi Kortela (23 Apr 2020 11:27 UTC)
Re: current directory and openat() et al Marc Feeley (23 Apr 2020 13:56 UTC)
Re: Review of SRFI 170 through 3.2 I/O Sebastien Marie (23 Apr 2020 13:32 UTC)
Definition of working directory Lassi Kortela (23 Apr 2020 13:51 UTC)
Re: Definition of working directory Marc Feeley (23 Apr 2020 14:06 UTC)
Re: Definition of working directory Sebastien Marie (23 Apr 2020 15:31 UTC)
Re: Review of SRFI 170 through 3.2 I/O Marc Nieper-Wißkirchen (23 Apr 2020 15:24 UTC)
Separate high-level and low-level APIs Lassi Kortela (23 Apr 2020 15:38 UTC)
Re: Separate high-level and low-level APIs Marc Nieper-Wißkirchen (23 Apr 2020 15:43 UTC)
Re: Separate high-level and low-level APIs Lassi Kortela (23 Apr 2020 15:48 UTC)
Re: Separate high-level and low-level APIs hga@xxxxxx (23 Apr 2020 16:19 UTC)
Re: Separate high-level and low-level APIs Lassi Kortela (23 Apr 2020 16:42 UTC)
Re: Review of SRFI 170 through 3.2 I/O hga@xxxxxx (23 Apr 2020 15:40 UTC)
Re: Review of SRFI 170 through 3.2 I/O Marc Feeley (23 Apr 2020 11:33 UTC)
Normalizing the current directory Lassi Kortela (23 Apr 2020 11:38 UTC)
Re: Normalizing the current directory Marc Feeley (23 Apr 2020 11:55 UTC)
Re: Normalizing the current directory Lassi Kortela (23 Apr 2020 12:09 UTC)
Per-thread working directory and umask proposal John Cowan (23 Apr 2020 14:13 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (23 Apr 2020 14:16 UTC)
Re: Per-thread working directory and umask proposal John Cowan (23 Apr 2020 16:07 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (23 Apr 2020 16:13 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (23 Apr 2020 16:25 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (23 Apr 2020 17:26 UTC)
Re: Per-thread working directory and umask proposal John Cowan (23 Apr 2020 18:38 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (23 Apr 2020 17:55 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (23 Apr 2020 18:55 UTC)
Re: Per-thread working directory and umask proposal John Cowan (23 Apr 2020 20:12 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (23 Apr 2020 22:17 UTC)
Re: Per-thread working directory and umask proposal Lassi Kortela (24 Apr 2020 08:43 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (24 Apr 2020 11:27 UTC)
Re: Per-thread working directory and umask proposal Lassi Kortela (24 Apr 2020 11:37 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (24 Apr 2020 12:22 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (24 Apr 2020 12:28 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (26 Apr 2020 09:19 UTC)
Re: Per-thread working directory and umask proposal John Cowan (27 Apr 2020 22:45 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (27 Apr 2020 23:42 UTC)
Re: Per-thread working directory and umask proposal John Cowan (28 Apr 2020 00:41 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (28 Apr 2020 00:56 UTC)
os-working-directory Lassi Kortela (29 Apr 2020 09:23 UTC)
Re: os-working-directory Duy Nguyen (29 Apr 2020 09:28 UTC)
current-umask Lassi Kortela (29 Apr 2020 09:43 UTC)
Windows Lassi Kortela (29 Apr 2020 09:47 UTC)
Re: Windows Lassi Kortela (29 Apr 2020 09:49 UTC)
Re: Windows John Cowan (29 Apr 2020 14:53 UTC)
Re: current-umask hga@xxxxxx (29 Apr 2020 13:14 UTC)
Re: current-umask Lassi Kortela (29 Apr 2020 13:25 UTC)
Re: current-umask Marc Feeley (29 Apr 2020 13:31 UTC)
Re: current-umask Marc Feeley (29 Apr 2020 13:45 UTC)
Re: current-umask Lassi Kortela (29 Apr 2020 14:12 UTC)
Re: current-umask hga@xxxxxx (29 Apr 2020 16:20 UTC)
Re: current-umask Lassi Kortela (29 Apr 2020 16:44 UTC)
Re: current-umask John Cowan (30 Apr 2020 04:02 UTC)
Re: os-working-directory John Cowan (30 Apr 2020 02:49 UTC)
Re: os-working-directory Lassi Kortela (30 Apr 2020 06:12 UTC)
Re: os-working-directory Sebastien Marie (30 Apr 2020 07:19 UTC)
Re: os-working-directory Sebastien Marie (30 Apr 2020 07:53 UTC)
Should the SRFI mandate current-directory per thread? Lassi Kortela (30 Apr 2020 12:14 UTC)
Re: Should the SRFI mandate current-directory per thread? Sebastien Marie (30 Apr 2020 17:00 UTC)
Re: Per-thread working directory and umask proposal hga@xxxxxx (28 Apr 2020 01:03 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (28 Apr 2020 01:41 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (30 Apr 2020 07:11 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (30 Apr 2020 11:33 UTC)

Re: current-umask Lassi Kortela 29 Apr 2020 14:12 UTC

> 1) Controlling the posix working directory and umask (that apply to the OS process)
> 2) The mapping of these concepts to Scheme threads
>
> So for the first there could be the procedures
>
> (posix-current-directory [ <dir> ])                that calls getcwd() or chdir()
> (posix-current-file-permission-mask [ <mask> ])    that calls umask()
>
> And for the second there could be the SRFI 39 parameters
>
> (current-directory [ <dir> ])                that reads or assigns the parameter
> (current-file-permission-mask [ <mask> ])    that reads or assigns the parameter

I like the symmetry.

Perhaps `posix-` should be `os-` since the current directory works using
Windows API as well and there's nothing intrinsically POSIX specific
about it. For the umask, there's a stronger case for `posix-`.

If `current-file-permission-mask` is designed with the option of being
portable to non-Unix platforms, then `<mask>` should probably be an
opaque object instead of an integer. That may be too fancy... perhaps we
should simply specify that it has OS-dependent meaning, and on POSIX
systems, an exact integer must be treated as a umask.

> Where current-directory would be initialized to (posix-current-directory) and current-file-permission-mask would be initialized to 0.

The OS kernel inescapably applies the process umask on top of the Scheme
per-thread umask. I don't think the process umask can be overridden (in
the way that the process working directory can be overridden by using an
absolute pathname instead of a relative one).

How do we communicate to users of SRFI 170 that the process umask is the
law and the per-thread umask is just something extra? The Scheme
implementation could zero out the process umask at the start, but it
doesn't help that much since users can change it back at any time...

Initializing the Scheme umask to 0 as you suggest would make it so that
only the process umask is in effect by default. That seems reasonable.

> Then (open-XXX-file <path>) would use the current-directory parameter and the current-file-permission-mask and the posix-current-file-permission-mask (combined with bitwise or).

Yes. (current-file-permission-mask and
posix-current-file-permission-mask would be combined implicitly by the
OS kernel.)