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
Using paths that are searchable but not completely readable hga@xxxxxx 23 Apr 2020 12:29 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 hga@xxxxxx 29 Apr 2020 16:20 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Wednesday, April 29, 2020 8:25 AM
>
>> I'm not sure about changing working-directory to
>> current-directory, the underlying POSIX procedure wide call getcwd
>> uses both....  Using both could be better, but if not that, I'd prefer
>> keeping working-directory.
>
> My argument is that all the other process/thread state stuff is called
> "current". The working directory is the only one that is called a
> "working" anything. (Does this imply everything else is "lazy"? :)
>
> Current-working would be two words for the same thing. "Working" in Unix
> doesn't refer to any other concept and is just a synonym for "current"
> AFAIK. The only other thing I can think of is "working set" and that's
> about CPU caches IIRC.

The working set can also refer to the set of pages that need to be
kept in main memory, or in the bad old days you'd thrash your hard
disk(s), for UNIX your swap partition(s).  Back when memory was dear,
drawing horizontal lines at the bottom of your screen to signal if
your process was running, paging, or for Lisp Machines, GCing was
comforting and/or annoying feedback.

I agree with dropping "working" from the SFRI.

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Wednesday, April 29, 2020 9:12 AM
>
>> 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.

As do I, and I thank Mr. Feeley for making this crystal clear, and
agree with his point about current-file-permission-mask being both
clear, and not onerous since it's not used very often.

> 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-`.

The vaguer the name, the more likely it can fit into situations we
haven't thought of, or maybe someday new systems.  So "os-" beats
"posix-", unless something is uniquely POSIX.  Which John just
reminded us does not include umasks for Windows, thanks to MS-DOS'
r/w permission bit.

Still, I continue to quibble about removing the "set-" uniformity of
the API.  Am I correct in understanding the motivation to do this is a
Scheme implementation performance hack of using parameter objects...??

Another option is removing "set-" as much as possible from the API,
but there's no obvious way to do that for set-file-mode/-owner/-group,
because you *get* those values using a single call to file-info, which
calls POSIX stat and returns a record mirroring stat's struct.

> 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.

Making it OS-dependent is the best, and it sounds like the restriction
you're advocating for exact integers is fairly safe and future proof.
The original UNIX permission mask is *not* a model to emulate, unless
you're directly copying it for backwards compatibility.

>> 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).

It can be changed, including "widened" to be less restrictive, but not
as trivially as supplying an absolute instead of relative pathname arg.

> 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...

Not the law if the thread changes the per process umask, rather, a
hierarchy.  We could "make it the law" as I previously proposed by not
letting it be widened, or maybe that would be better put in a security
SRFI, to possibly include things like OpenBSD's pledge, as in "I pledge
not to do X, Y, and Z in the future".

> 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.

That works, but makes accidents more likely in the per thread code.

> [...]

- Harold