Am 24.03.2021 um 21:58 schrieb 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:
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?
To the best of my knowledge it's WSL1.
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
Here it gets a bit weird. The result of that procedure depends on
whether the link target, 'foo', exists in cygwin64/tmp prior to running
the above commands.
If 'foo' exists, the copy of the symlink becomes a Windows native
symlink (reparse point class 0xa000000c). If it doesn't the copy turns
into a reparse point of class 0xa000001d, which 'fsutil reparsepoint
query' decodes as "name replacement", Cygwin as a (broken) symlink, and
'dir' lists as <JUNCTION>. In other words, a WSL symlink.
It's quite strange that copying a native WSL1 symlink from inside WSL's
own file system out into the Windows side of things does _not_ always
yield an identical copy. Some layer sitting between WSL and the Windows
file system may modify the copy in flight.
The same difference applies if, instead of copying an existing symlink,
you just have WSL create one directly in the Windows tree, i.e.
cd /mnt/c/cygwin64/tmp
rm a b
touch a
ln -s a la
ln -s b lb
touch b
yields a Windows symlink for 'la', and a WSL symlink for 'lb'.
