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
