From: Thomas Wolff <towo@towo.net>
To: cygwin@cygwin.com
Subject: Re: WSL symbolic links
Date: Fri, 27 Mar 2020 13:24:30 +0100 [thread overview]
Message-ID: <ba4000a3-74d2-2a3c-f6ea-6bf4fa934b8b@towo.net> (raw)
In-Reply-To: <20200327112115.GL3261@calimero.vinschen.de>
Am 27.03.2020 um 12:21 schrieb 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.
Works, great, thank you!
> 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.
As Windows filenames are character strings as opposed to Linux filenames
which are byte strings, some strange behaviour is unavoidable. I see:
$ wsl ls -l link_LW
lrwxrwxrwx 1 towo towo 19 Mar 27 12:11 link_LW ->
file_L_
$ ls -l link_LW
lrwxrwxrwx 1 towo Kein 11 27. Mrz 13:11 link_LW -> file_L_����
which looks OK for me.
Thomas
next prev parent reply other threads:[~2020-03-27 12:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-26 9:00 Thomas Wolff
2020-03-26 11:00 ` Corinna Vinschen
2020-03-26 16:15 ` Thomas Wolff
2020-03-26 19:12 ` Brian Inglis
2020-03-26 19:56 ` Corinna Vinschen
2020-03-26 23:52 ` Thomas Wolff
2020-03-27 5:46 ` ASSI
2020-03-27 11:21 ` Corinna Vinschen
2020-03-27 12:24 ` Thomas Wolff [this message]
2020-03-27 13:01 ` Corinna Vinschen
2020-03-27 14:43 ` Thomas Wolff
2020-03-26 20:05 ` Corinna Vinschen
2020-03-27 17:58 ` Brian Inglis
2020-03-27 18:53 ` Corinna Vinschen
2020-03-28 3:32 ` Brian Inglis
2020-03-28 10:31 ` Henry S. Thompson
2020-03-28 11:30 ` Thomas Wolff
2020-03-28 11:59 ` Andrey Repin
2020-03-28 20:45 ` Brian Inglis
2020-03-29 11:52 ` Andrey Repin
2020-03-30 8:46 ` Corinna Vinschen
2020-04-04 14:32 ` Denis Excoffier
2020-04-05 15:22 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ba4000a3-74d2-2a3c-f6ea-6bf4fa934b8b@towo.net \
--to=towo@towo.net \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).