Re: [PATCH 0/2] Provide virtual /dev/fd and /dev/{stdin,stdout,stderr} symlinks

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Brian,

On Fri, 25 Feb 2022, Brian Inglis wrote:

> On 2022-02-21 06:36, Johannes Schindelin wrote:
> > These symbolic links are crucial e.g. to support process substitution
> > (Bash's
> > very nice `<(SOME-COMMAND)` feature).
> >
> > For various reasons, it is a bit cumbersome (or impossible) to generate
> > these
> > symbolic links in all circumstances where Git for Windows wants to use its
> > close fork of the Cygwin runtime.
> >
> > Therefore, let's just handle these symbolic links as implicit, virtual ones.
> >
> > If there is appetite for it, I wonder whether we should do something similar
> > for `/dev/shm` and `/dev/mqueue`? Are these even still used in Cygwin?
>
> Looks like that would make sense, as Cygwin appears to create all of those
> only on first startup (and probably rechecks if they need created every
> startup) e.g.
>
> Cygwin-32 $ ls -Fglot /dev/ | tail -6
> lrwxrwxrwx  1       13 Apr 29  2012 fd -> /proc/self/fd/
> lrwxrwxrwx  1       15 Apr 29  2012 stderr -> /proc/self/fd/2
> lrwxrwxrwx  1       15 Apr 29  2012 stdout -> /proc/self/fd/1|
> lrwxrwxrwx  1       15 Apr 29  2012 stdin -> /proc/self/fd/0
> drwxr-xr-x+ 1        0 Apr 29  2012 mqueue/
> drwxr-xr-x+ 1        0 Apr 29  2012 shm/
>
> Cygwin-64 $ ls -Fglot /dev/ | tail -6
> drwxrwxrwt+ 1        0 Dec  2  2017 shm/
> lrwxrwxrwx  1       13 May 14  2013 fd -> /proc/self/fd/
> lrwxrwxrwx  1       15 May 14  2013 stderr -> /proc/self/fd/2
> lrwxrwxrwx  1       15 May 14  2013 stdout -> /proc/self/fd/1|
> lrwxrwxrwx  1       15 May 14  2013 stdin -> /proc/self/fd/0
> drwxrwxrwt+ 1        0 May 14  2013 mqueue/
>
> so they would all get 2006-12-01 00:00:00+0000 birth time.
>
> [Looks like I ran something using shm in 2017!]

Thank you for that additional context!

As Corinna pointed out, the directories currently need to exist on disk
(so that mmap()able files can be created in them), though, and even if
there _might_ be a way to avoid this (which would be good, in Git for
Windows' context, where the runtime's pseudo root directory is inside
`C:\Program Files`, i.e. read-only) it looks like a bit too much of a
challenge for me to take on, at least for now.

Ciao,
Johannes