WSL symbolic links

[Corinna Vinschen]

On Mar 27 00:52, Thomas Wolff wrote:
> Am 26.03.2020 um 20:56 schrieb Corinna Vinschen:
> > This is a reparse point tag different from the normal Windows symlink
> > reparse point tag, 0xa000000c.  Searching for this value shows this
> > is defined in ntifs.h as IO_REPARSE_TAG_LX_SYMLINK.
> > 
> > Unfortunately I don't see a definition of the reparse point data for
> > that reparse point type.
> > 
> > In your examples the data part looks like a 4 byte int value, being 2 in
> > both of your examples, maybe a file type, followed by the path in
> > multibyte, no trailing \0.
> > 
> > Unfortunately, in both cases the path is relative, just the file name it
> > points to.  To get more information, could one of you two please create
> > a few more symlinks?
> > 
> > - A symlink pointing to a local path, given in absolute path syntax.
> >    I assume the path will be in POSIX syntax, contain slashes, but it
> >    would be helpful to see it.
> > 
> > - A symlink with a target path pointing to a remote file (what syntax
> >    does this use?)
> > 
> > - Last but not least, could you please create a symlink pointing to a
> >    target with a non-ASCII char, e. g., some german umlaut?
> Not sure what kind of remote you'd like to see. I have a 'net use'
> (cifs/smbfs) mounted drive but couldn't mount it in WSL. Otherwise:
> 
> > wsl -d Ubuntu ls -l link*
> lrwxrwxrwx 1 towo towo  4 Mar 27 00:31 link -> file
> lrwxrwxrwx 1 towo towo 15 Mar 27 00:31 link-abs -> /mnt/c/tmp/file
> lrwxrwxrwx 1 towo towo  5 Mar 27 00:39 link-foo -> föö
> lrwxrwxrwx 1 towo towo 16 Mar 27 00:39 link-foo-abs -> /mnt/c/tmp/föö
> > rd-reparse '\??\C:\tmp\link' ; echo
> ReparseTag:           0xa000001d
> ReparseDataLength:             8
> Reserved:                      0
> 02 00 00 00 66 69 6c 65
> > rd-reparse '\??\C:\tmp\link-abs' ; echo
> ReparseTag:           0xa000001d
> ReparseDataLength:            19
> Reserved:                      0
> 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66
> 69 6c 65
> > rd-reparse '\??\C:\tmp\link-foo' ; echo
> ReparseTag:           0xa000001d
> ReparseDataLength:             9
> Reserved:                      0
> 02 00 00 00 66 c3 b6 c3 b6
> > rd-reparse '\??\C:\tmp\link-foo-abs' ; echo
> ReparseTag:           0xa000001d
> ReparseDataLength:            20
> Reserved:                      0
> 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66
> c3 b6 c3 b6

Thanks!  In the meantime I could fix my problems with the Windows Store
and was finally able to install WSL for further testing.  See below.

> If the link name itself contains non-ASCII, rd-reparse fails with
> NtOpenFile: C0000034

Yeah, that's expected.  The test app only handles filename with ASCII
chars.

> > It's questionable if supporting this new symlink type makes sense, but
> > taking a closer look doesn't hurt, I guess.
> Well, at least they should be deletable, I think.

I debugged this now and I found that practically all problems, including
the inability to delete the symlink, are a result of not being able to
open the reparse point correctly as reparse point within Cygwin.  So as
not to destroy something important, Cygwin only opens reparse points as
reparse points if it recognizes the reparse point type.

Consequentially, all immediate problems go away, as soon as Cygwin
recognizes and handles the symlink :)

So I created a patch and pushed it.  The latest developer snapshot from
https://cygwin.com/snapshots/ contains this patch.

Funny sidenote: Assuming you create symlinks pointing to files with
non-UTF-8 chars, e. g., umlauts in ISO-8859-1, then the symlink converts
*all* these chars to the Unicode REPLACEMENT CHARACTER 0xfffd.  I assume
this will also happen if you try to create the file with these chars in
the first place, so it's not much of a problem.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20200327/5ffce4b8/attachment.sig>