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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
