[PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links

[Ken Brown]

On 3/24/2021 2:55 PM, Hans-Bernhard Bröker wrote:
> Am 23.03.2021 um 10:30 schrieb Corinna Vinschen via Cygwin-patches:
>  > On Mar 22 22:54, Hans-Bernhard Bröker wrote:
>  >> Am 22.03.2021 um 16:22 schrieb Johannes Schindelin:
>  >>> One of those under-documented reparse point types is the WSL symbolic
>  >>> link, which you will notice are supported in Cygwin, removing quite some
>  >>> sway from your argument...
>  >>
>  >> I notice no such thing right now, running the currently available release
>  >> version 3.1.7:
>  >>
>  >> stat: cannot stat '//wsl$/Debian/home/hbbro/link_to_a': Input/output error
>  >
>  > What type of WSL symlink is that?
> 
> It's what WSL Debian creates when I 'ln -s' inside its own filesystem.
> 
> Windows' own "dir" command shows it as
> 
> 22.03.2021  22:34    <JUNCTION>     link_to_a [...]
> 
> But it cannot do anything else with it.  Even fsutil doesn't work on that thing:
> 
> C:\prg\test>fsutil reparsePoint query \\wsl$\Debian\home\hbbro
> Fehler:  Unzulässige Funktion.

Are you running WSL1 or WSL2?  I have WSL1, and the stat command such as the one 
you tried fails in the same way as yours.  Nevertheless, a symlink created under 
WSL is indeed recognized as such by Cygwin.  I verified this as follows:

1. Within WSL,

$ ln -s foo mysymlink
$ cp -a mysymlink /mnt/c/cygwin64/tmp

2. Within Cygwin,

$ stat /tmp/mysymlink
   File: /tmp/mysymlink -> foo
   Size: 3               Blocks: 0          IO Block: 65536  symbolic link
Device: 74d6767bh/1960212091d   Inode: 25614222880728371  Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (197609/  kbrown)   Gid: (197121/    None)
Access: 2021-03-24 16:25:50.729219700 -0400
Modify: 2021-03-24 16:25:50.729219700 -0400
Change: 2021-03-24 16:27:13.979376200 -0400
  Birth: 2021-03-24 16:27:13.979376200 -0400

3. I then ran the stat command under gdb with a breakpoint at 
check_reparse_point_target and verified that Cygwin recognized /tmp/mysymlink as 
a WSL symlink (IO_REPARSE_TAG_LX_SYMLINK).

Someone with WSL2 should try a similar experiment to make sure that the symlink 
representation as a reparse point hasn't changed.

As to the failure of the stat command that you tried, I suspect it is related to 
the '\\wsl$' magic rather than anything to do with the symlink itself.  If you 
run that stat command under strace, you'll see that Cygwin calls NtCreateFile 
(\??\UNC\wsl$\...), which succeeds, and then calls 
NtFsControlFile(FSCTL_GET_REPARSE_POINT), which fails with STATUS_NOT_IMPLEMENTED.

Ken