WSL symbolic links

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

WSL symbolic links

Thomas Wolff
A symbolic link created with WSL is neither interpreted in cygwin nor
can it be deleted:
 > touch file
 > wsl ln -s file link
 > wsl ls -l link
lrwxrwxrwx    1 towo     towo             1 Mar 26 08:56 link -> file
 > ls -l link
-rw-r----- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link
 > rm -f link
/bin/rm: cannot remove 'link': Permission denied (even as admin)
 > cmd /c del link
works.
--
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
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Corinna Vinschen-2
On Mar 26 10:00, Thomas Wolff wrote:
> A symbolic link created with WSL is neither interpreted in cygwin nor can it
> be deleted:
> > touch file
> > wsl ln -s file link
> > wsl ls -l link
> lrwxrwxrwx    1 towo     towo             1 Mar 26 08:56 link -> file
> > ls -l link
> -rw-r----- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link

What kind of file are they in the real world?  Reparse points?  If so,
what content do they have?  I attached a Q&D source from my vault
of old test apps to check on reparse point content.  Please compile with

  gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll

It takes a single native NT path as parameter, kind of like this:

  ./rd-reparse '\??\C:\cygwin64\home\corinna\link'


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer

--
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

rd-reparse.c (3K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Thomas Wolff
Am 26.03.2020 um 12:00 schrieb Corinna Vinschen:

> On Mar 26 10:00, Thomas Wolff wrote:
>> A symbolic link created with WSL is neither interpreted in cygwin nor can it
>> be deleted:
>>> touch file
>>> wsl ln -s file link
>>> wsl ls -l link
>> lrwxrwxrwx    1 towo     towo             1 Mar 26 08:56 link -> file
>>> ls -l link
>> -rw-r----- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link
> What kind of file are they in the real world?  Reparse points?  If so,
> what content do they have?  I attached a Q&D source from my vault
> of old test apps to check on reparse point content.  Please compile with
>
>    gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll
>
> It takes a single native NT path as parameter, kind of like this:
>
>    ./rd-reparse '\??\C:\cygwin64\home\corinna\link'
output is:
ReparseTag:           0xa000001d
ReparseDataLength:             8
Reserved:                      0
02 00 00 00 66 69 6c 65

>
>
> Thanks,
> Corinna
>
>
> --
> 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

--
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
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Brian Inglis
In reply to this post by Corinna Vinschen-2
On 2020-03-26 05:00, Corinna Vinschen wrote:

> On Mar 26 10:00, Thomas Wolff wrote:
>> A symbolic link created with WSL is neither interpreted in cygwin nor can it
>> be deleted:
>>> touch file
>>> wsl ln -s file link
>>> wsl ls -l link
>> lrwxrwxrwx    1 towo     towo             1 Mar 26 08:56 link -> file
>>> ls -l link
>> -rw-r----- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link
> What kind of file are they in the real world?  Reparse points?  If so,
> what content do they have?  I attached a Q&D source from my vault
> of old test apps to check on reparse point content.  Please compile with
>   gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll
> It takes a single native NT path as parameter, kind of like this:
>   ./rd-reparse '\??\C:\cygwin64\home\corinna\link'

They should be WSL or Windows mklink (soft) links, and the reason why mklink was
allowed unelevated in Windows 10 with Developer mode.

In an *elevated* shell:

$ ls -dln u
-rw-r----- 1 4294967295 4294967295 0 Nov  9 06:09 u
$ getfacl u
getfacl: u: Permission denied
$ icacls u
u NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
  $HOSTNAME\$USER:(F)
  $HOSTNAME\$USER:(RX,W,DC)
  BUILTIN\Users:(Rc,S,RA)
  BUILTIN\Administrators:(RX,W,DC)
  BUILTIN\Users:(DENY)(S,RD,REA,X)
  Everyone:(RX)
  NT AUTHORITY\SYSTEM:(I)(F)
  BUILTIN\Administrators:(I)(F)
  $HOSTNAME\$USER:(I)(F)

Successfully processed 1 files; Failed processing 0 files
$ ./rd-reparse '\??\C:\...\u'
ReparseTag:           0xa000001d
ReparseDataLength:             5
Reserved:                      0
02 00 00 00 75

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
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
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Corinna Vinschen-2
Brian and Thomas,


Thanks to both of you for providing this info.


On Mar 26 13:12, Brian Inglis wrote:

> On 2020-03-26 05:00, Corinna Vinschen wrote:
> > On Mar 26 10:00, Thomas Wolff wrote:
> >> A symbolic link created with WSL is neither interpreted in cygwin nor can it
> >> be deleted:
> >>> touch file
> >>> wsl ln -s file link
> >>> wsl ls -l link
> >> lrwxrwxrwx    1 towo     towo             1 Mar 26 08:56 link -> file
> >>> ls -l link
> >> -rw-r----- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link
> > What kind of file are they in the real world?  Reparse points?  If so,
> > what content do they have?  I attached a Q&D source from my vault
> > of old test apps to check on reparse point content.  Please compile with
> >   gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll
> > It takes a single native NT path as parameter, kind of like this:
> >   ./rd-reparse '\??\C:\cygwin64\home\corinna\link'
>
> They should be WSL or Windows mklink (soft) links, and the reason why mklink was
> allowed unelevated in Windows 10 with Developer mode.
>
> In an *elevated* shell:
>
> $ ls -dln u
> -rw-r----- 1 4294967295 4294967295 0 Nov  9 06:09 u
> $ getfacl u
> getfacl: u: Permission denied
> $ icacls u
> u NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
>   $HOSTNAME\$USER:(F)
>   $HOSTNAME\$USER:(RX,W,DC)
>   BUILTIN\Users:(Rc,S,RA)
>   BUILTIN\Administrators:(RX,W,DC)
>   BUILTIN\Users:(DENY)(S,RD,REA,X)
>   Everyone:(RX)
>   NT AUTHORITY\SYSTEM:(I)(F)
>   BUILTIN\Administrators:(I)(F)
>   $HOSTNAME\$USER:(I)(F)
>
> Successfully processed 1 files; Failed processing 0 files
> $ ./rd-reparse '\??\C:\...\u'
> ReparseTag:           0xa000001d
                        ^^^^^^^^^^

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?

It's questionable if supporting this new symlink type makes sense, but
taking a closer look doesn't hurt, I guess.


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer

--
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Corinna Vinschen-2
In reply to this post by Brian Inglis
On Mar 26 13:12, Brian Inglis wrote:

> On 2020-03-26 05:00, Corinna Vinschen wrote:
> > On Mar 26 10:00, Thomas Wolff wrote:
> >> A symbolic link created with WSL is neither interpreted in cygwin nor can it
> >> be deleted:
> >>> touch file
> >>> wsl ln -s file link
> >>> wsl ls -l link
> >> lrwxrwxrwx    1 towo     towo             1 Mar 26 08:56 link -> file
> >>> ls -l link
> >> -rw-r----- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link
> > What kind of file are they in the real world?  Reparse points?  If so,
> > what content do they have?  I attached a Q&D source from my vault
> > of old test apps to check on reparse point content.  Please compile with
> >   gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll
> > It takes a single native NT path as parameter, kind of like this:
> >   ./rd-reparse '\??\C:\cygwin64\home\corinna\link'
>
> They should be WSL or Windows mklink (soft) links, and the reason why mklink was
> allowed unelevated in Windows 10 with Developer mode.
>
> In an *elevated* shell:
>
> $ ls -dln u
> -rw-r----- 1 4294967295 4294967295 0 Nov  9 06:09 u
               ^^^^^^^^^^^^^^^^^^^^^
This is unknown user, unknown group, which means, the Windows
function LookupAccountSid() probably returned a domain name which
is unknown (neither account domain, nor primary, nor trusted domain).

An strace of `ls -l u' may be helpful...

> $ getfacl u
> getfacl: u: Permission denied
> $ icacls u
> u NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
>   $HOSTNAME\$USER:(F)
    ^^^^^^^^^^^^^^^
    Is that the *real* output, or did you tamper with it?


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer

--
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Thomas Wolff
In reply to this post by Corinna Vinschen-2
Am 26.03.2020 um 20:56 schrieb Corinna Vinschen:

> Brian and Thomas,
>
>
> Thanks to both of you for providing this info.
>
>
> On Mar 26 13:12, Brian Inglis wrote:
>> On 2020-03-26 05:00, Corinna Vinschen wrote:
>>> On Mar 26 10:00, Thomas Wolff wrote:
>>>> A symbolic link created with WSL is neither interpreted in cygwin nor can it
>>>> be deleted:
>>>>> touch file
>>>>> wsl ln -s file link
>>>>> wsl ls -l link
>>>> lrwxrwxrwx    1 towo     towo             1 Mar 26 08:56 link -> file
>>>>> ls -l link
>>>> -rw-r----- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link
>>> What kind of file are they in the real world?  Reparse points?  If so,
>>> what content do they have?  I attached a Q&D source from my vault
>>> of old test apps to check on reparse point content.  Please compile with
>>>    gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll
>>> It takes a single native NT path as parameter, kind of like this:
>>>    ./rd-reparse '\??\C:\cygwin64\home\corinna\link'
>> They should be WSL or Windows mklink (soft) links, and the reason why mklink was
>> allowed unelevated in Windows 10 with Developer mode.
>>
>> In an *elevated* shell:
>>
>> $ ls -dln u
>> -rw-r----- 1 4294967295 4294967295 0 Nov  9 06:09 u
>> $ getfacl u
>> getfacl: u: Permission denied
>> $ icacls u
>> u NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
>>    $HOSTNAME\$USER:(F)
>>    $HOSTNAME\$USER:(RX,W,DC)
>>    BUILTIN\Users:(Rc,S,RA)
>>    BUILTIN\Administrators:(RX,W,DC)
>>    BUILTIN\Users:(DENY)(S,RD,REA,X)
>>    Everyone:(RX)
>>    NT AUTHORITY\SYSTEM:(I)(F)
>>    BUILTIN\Administrators:(I)(F)
>>    $HOSTNAME\$USER:(I)(F)
>>
>> Successfully processed 1 files; Failed processing 0 files
>> $ ./rd-reparse '\??\C:\...\u'
>> ReparseTag:           0xa000001d
>                          ^^^^^^^^^^
>
> 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
 >

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

> 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.
Thomas

>
>
> Thanks,
> Corinna
>
>
> --
> 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

--
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
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Achim Gratz
Thomas Wolff writes:
>> - 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:

That's exactly why WSL is so nearly useless to me and why Cygwin
continues to hold its place.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
--
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
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Corinna Vinschen-2
In reply to this post by Thomas Wolff
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

--
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Thomas Wolff
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
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Corinna Vinschen-2
On Mar 27 13:24, Thomas Wolff wrote:

> Am 27.03.2020 um 12:21 schrieb Corinna Vinschen:
> > On Mar 27 00:52, Thomas Wolff wrote:
> > > [...]
> > > > 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
> > [...]
> > 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!
Thanks for testing!

> > 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.
Not sure I expressed myself correctly there.  What I was trying to say
is, the symlink created by WSL already contains the 0xfffd replacement
char, in UTF-8 \xef \xbf \xbd.  So the info is already lost inside the
symlink.


Corinna

--
Corinna Vinschen
Cygwin Maintainer

--
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Thomas Wolff
Am 27.03.2020 um 14:01 schrieb Corinna Vinschen:

> On Mar 27 13:24, Thomas Wolff wrote:
>> Am 27.03.2020 um 12:21 schrieb Corinna Vinschen:
>>> On Mar 27 00:52, Thomas Wolff wrote:
>>>> [...]
>>>>> 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
>>> [...]
>>> 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!
> Thanks for testing!
>
>>> 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.
> Not sure I expressed myself correctly there.  What I was trying to say
> is, the symlink created by WSL already contains the 0xfffd replacement
> char, in UTF-8 \xef \xbf \xbd.  So the info is already lost inside the
> symlink.
I couldn't create a non-UTF8 file name in WSL on the command line; even
running LC_ALL=de_DE mintty and running WSL LC_ALL=de_DE bash, keyboard
input would still appear as UTF-8 when displayed with od, which is weird.
Anyway, this can be tricked using touch from a script file of course. In
that case, indeed WSL flattens all invalid characters to � already for
the filename.
However, all symbolic link cases work for me. I can point links to
file_L_ and file_LW_���� and access the respective files correctly
via the links from both WSL and cygwin now.
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
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Brian Inglis
In reply to this post by Corinna Vinschen-2
On 2020-03-26 14:05, Corinna Vinschen wrote:

> On Mar 26 13:12, Brian Inglis wrote:
>> On 2020-03-26 05:00, Corinna Vinschen wrote:
>>> On Mar 26 10:00, Thomas Wolff wrote:
>>>> A symbolic link created with WSL is neither interpreted in cygwin nor can it
>>>> be deleted:
>>>>> touch file
>>>>> wsl ln -s file link
>>>>> wsl ls -l link
>>>> lrwxrwxrwx    1 towo     towo             1 Mar 26 08:56 link -> file
>>>>> ls -l link
>>>> -rw-r----- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link
>>> What kind of file are they in the real world?  Reparse points?  If so,
>>> what content do they have?  I attached a Q&D source from my vault
>>> of old test apps to check on reparse point content.  Please compile with
>>>   gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll
>>> It takes a single native NT path as parameter, kind of like this:
>>>   ./rd-reparse '\??\C:\cygwin64\home\corinna\link'
>> They should be WSL or Windows mklink (soft) links, and the reason why mklink was
>> allowed unelevated in Windows 10 with Developer mode.
>> In an *elevated* shell:
>> $ ls -dln u
>> -rw-r----- 1 4294967295 4294967295 0 Nov  9 06:09 u
>                ^^^^^^^^^^^^^^^^^^^^^
> This is unknown user, unknown group, which means, the Windows
> function LookupAccountSid() probably returned a domain name which
> is unknown (neither account domain, nor primary, nor trusted domain).
>
> An strace of `ls -l u' may be helpful...
Attached with startup environment, locale, and message setup cut (reduced by
100KB), and rest sanitized as below. Could DM/PM original on request.

>> $ getfacl u
>> getfacl: u: Permission denied
>> $ icacls u
>> u NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
>>   $HOSTNAME\$USER:(F)
>     ^^^^^^^^^^^^^^^
>     Is that the *real* output, or did you tamper with it?

Sanitized with a script I use on posted output in case I forget to use aliases
like llgo (ls -lgo).
Created the script for cygcheck -hrsv output in case I forget, now run from
permanent postinstall script in background, as it takes a while if needed, and
my desktop environments are messy with stuff from ~/.bash_... setup scripts.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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

ls-l.strace.txt (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Corinna Vinschen-2
On Mar 27 11:58, Brian Inglis wrote:

> On 2020-03-26 14:05, Corinna Vinschen wrote:
> > On Mar 26 13:12, Brian Inglis wrote:
> >> On 2020-03-26 05:00, Corinna Vinschen wrote:
> >>> On Mar 26 10:00, Thomas Wolff wrote:
> >>>> A symbolic link created with WSL is neither interpreted in cygwin nor can it
> >>>> be deleted:
> >>>>> touch file
> >>>>> wsl ln -s file link
> >>>>> wsl ls -l link
> >>>> lrwxrwxrwx    1 towo     towo             1 Mar 26 08:56 link -> file
> >>>>> ls -l link
> >>>> -rw-r----- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link
> >>> What kind of file are they in the real world?  Reparse points?  If so,
> >>> what content do they have?  I attached a Q&D source from my vault
> >>> of old test apps to check on reparse point content.  Please compile with
> >>>   gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll
> >>> It takes a single native NT path as parameter, kind of like this:
> >>>   ./rd-reparse '\??\C:\cygwin64\home\corinna\link'
> >> They should be WSL or Windows mklink (soft) links, and the reason why mklink was
> >> allowed unelevated in Windows 10 with Developer mode.
> >> In an *elevated* shell:
> >> $ ls -dln u
> >> -rw-r----- 1 4294967295 4294967295 0 Nov  9 06:09 u
> >                ^^^^^^^^^^^^^^^^^^^^^
> > This is unknown user, unknown group, which means, the Windows
> > function LookupAccountSid() probably returned a domain name which
> > is unknown (neither account domain, nor primary, nor trusted domain).
> >
> > An strace of `ls -l u' may be helpful...
>
> Attached with startup environment, locale, and message setup cut (reduced by
> 100KB), and rest sanitized as below. Could DM/PM original on request.
Thanks!  This should already be fixed in the latest developer snapshot
after I was finally able to install WSL myself.  See my reply to Thomas
in https://sourceware.org/pipermail/cygwin/2020-March/244211.html

All the effects are a result of not opening the reparse point as reparse
point, as weird as it sounds at first :)


Corinna

--
Corinna Vinschen
Cygwin Maintainer

--
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Brian Inglis
On 2020-03-27 12:53, Corinna Vinschen wrote:

> On Mar 27 11:58, Brian Inglis wrote:
>> On 2020-03-26 14:05, Corinna Vinschen wrote:
>>> On Mar 26 13:12, Brian Inglis wrote:
>>>> On 2020-03-26 05:00, Corinna Vinschen wrote:
>>>>> On Mar 26 10:00, Thomas Wolff wrote:
>>>>>> A symbolic link created with WSL is neither interpreted in cygwin nor can it
>>>>>> be deleted:
>>>>>>> touch file
>>>>>>> wsl ln -s file link
>>>>>>> wsl ls -l link
>>>>>> lrwxrwxrwx    1 towo     towo             1 Mar 26 08:56 link -> file
>>>>>>> ls -l link
>>>>>> -rw-r----- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link
>>>>> What kind of file are they in the real world?  Reparse points?  If so,
>>>>> what content do they have?  I attached a Q&D source from my vault
>>>>> of old test apps to check on reparse point content.  Please compile with
>>>>>   gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll
>>>>> It takes a single native NT path as parameter, kind of like this:
>>>>>   ./rd-reparse '\??\C:\cygwin64\home\corinna\link'
>>>> They should be WSL or Windows mklink (soft) links, and the reason why mklink was
>>>> allowed unelevated in Windows 10 with Developer mode.
>>>> In an *elevated* shell:
>>>> $ ls -dln u
>>>> -rw-r----- 1 4294967295 4294967295 0 Nov  9 06:09 u
>>>                ^^^^^^^^^^^^^^^^^^^^^
>>> This is unknown user, unknown group, which means, the Windows
>>> function LookupAccountSid() probably returned a domain name which
>>> is unknown (neither account domain, nor primary, nor trusted domain).
>>>
>>> An strace of `ls -l u' may be helpful...
>>
>> Attached with startup environment, locale, and message setup cut (reduced by
>> 100KB), and rest sanitized as below. Could DM/PM original on request.
>
> Thanks!  This should already be fixed in the latest developer snapshot
> after I was finally able to install WSL myself.  See my reply to Thomas
> in https://sourceware.org/pipermail/cygwin/2020-March/244211.html
>
> All the effects are a result of not opening the reparse point as reparse
> point, as weird as it sounds at first :)

Would you consider that test program a reasonable base for something I have
wished for a while: a program that would classify a file name as a (regular)
hard link, a Windows directory or file link, a junction, a Windows shortcut, a
Cygwin symlink, a Unix/WSL symlink, a URL link, and/or tell me where it links to
etc. Thinking of hacking that plus maybe bits of file, cygpath, readshortcut,
readlink, lsattr together to display otherwise awkward to access attributes and
properties.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
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
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Cygwin list mailing list
Brian Inglis writes:

> ...  wished for a while: a program that would classify a file name as
> a (regular) hard link, a Windows directory or file link, a junction, a
> Windows shortcut, a Cygwin symlink, a Unix/WSL symlink, a URL link,
> and/or tell me where it links to etc. Thinking of hacking that plus
> maybe bits of file, cygpath, readshortcut, readlink, lsattr together
> to display otherwise awkward to access attributes and properties.

Oh, yes please!  You could call it 'swan', for Swiss Army Knife :-).

ht
--
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [hidden email]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Thomas Wolff
Am 28.03.2020 um 11:31 schrieb Henry S. Thompson via Cygwin:
> Brian Inglis writes:
>
>> ...  wished for a while: a program that would classify a file name as
>> a (regular) hard link, a Windows directory or file link, a junction, a
>> Windows shortcut, a Cygwin symlink, a Unix/WSL symlink, a URL link,
>> and/or tell me where it links to etc. Thinking of hacking that plus
>> maybe bits of file, cygpath, readshortcut, readlink, lsattr together
>> to display otherwise awkward to access attributes and properties.
> Oh, yes please!  You could call it 'swan', for Swiss Army Knife :-).
Or maybe simply an additional option for `ls -l`?
--
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
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Andrey Repin
In reply to this post by Brian Inglis
Greetings, Brian Inglis!

>>
>> Thanks!  This should already be fixed in the latest developer snapshot
>> after I was finally able to install WSL myself.  See my reply to Thomas
>> in https://sourceware.org/pipermail/cygwin/2020-March/244211.html
>>
>> All the effects are a result of not opening the reparse point as reparse
>> point, as weird as it sounds at first :)

> Would you consider that test program a reasonable base for something I have
> wished for a while: a program that would classify a file name as a (regular)
> hard link, a Windows directory or file link, a junction, a Windows shortcut, a
> Cygwin symlink, a Unix/WSL symlink, a URL link, and/or tell me where it links to
> etc. Thinking of hacking that plus maybe bits of file, cygpath, readshortcut,
> readlink, lsattr together to display otherwise awkward to access attributes and
> properties.

I'd like to see it as part of "file -h" functionality.


--
With best regards,
Andrey Repin
Saturday, March 28, 2020 14:52:04

Sorry for my terrible english...

--
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
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Brian Inglis
On 2020-03-28 05:59, Andrey Repin wrote:

> Greetings, Brian Inglis!
>
>>>
>>> Thanks!  This should already be fixed in the latest developer snapshot
>>> after I was finally able to install WSL myself.  See my reply to Thomas
>>> in https://sourceware.org/pipermail/cygwin/2020-March/244211.html
>>>
>>> All the effects are a result of not opening the reparse point as reparse
>>> point, as weird as it sounds at first :)
>
>> Would you consider that test program a reasonable base for something I have
>> wished for a while: a program that would classify a file name as a (regular)
>> hard link, a Windows directory or file link, a junction, a Windows shortcut, a
>> Cygwin symlink, a Unix/WSL symlink, a URL link, and/or tell me where it links to
>> etc. Thinking of hacking that plus maybe bits of file, cygpath, readshortcut,
>> readlink, lsattr together to display otherwise awkward to access attributes and
>> properties.
>
> I'd like to see it as part of "file -h" functionality.

Both file and grep are getting worse at distinguishing UTF-8 from binary data,
so I don't want to get into fiddling with that recognizer/interpreter, given
that it can not get or use that information as is, just enough of file to decide
on or verify a file type;
for ls: link classification is outside its remit; and
swan (SWiss Army kNife) is too vague and wide for my taste: a sharper tool and a
more focussed name depending on eventual function like lslink.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
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
Reply | Threaded
Open this post in threaded view
|

Re: WSL symbolic links

Andrey Repin
Greetings, Brian Inglis!

> On 2020-03-28 05:59, Andrey Repin wrote:
>> Greetings, Brian Inglis!
>>
>>>>
>>>> Thanks!  This should already be fixed in the latest developer snapshot
>>>> after I was finally able to install WSL myself.  See my reply to Thomas
>>>> in https://sourceware.org/pipermail/cygwin/2020-March/244211.html
>>>>
>>>> All the effects are a result of not opening the reparse point as reparse
>>>> point, as weird as it sounds at first :)
>>
>>> Would you consider that test program a reasonable base for something I have
>>> wished for a while: a program that would classify a file name as a (regular)
>>> hard link, a Windows directory or file link, a junction, a Windows shortcut, a
>>> Cygwin symlink, a Unix/WSL symlink, a URL link, and/or tell me where it links to
>>> etc. Thinking of hacking that plus maybe bits of file, cygpath, readshortcut,
>>> readlink, lsattr together to display otherwise awkward to access attributes and
>>> properties.
>>
>> I'd like to see it as part of "file -h" functionality.

> Both file and grep are getting worse at distinguishing UTF-8 from binary data,
> so I don't want to get into fiddling with that recognizer/interpreter, given
> that it can not get or use that information as is, just enough of file to decide
> on or verify a file type;

I did mean that. Something like "Windows symbolic link - file" or "Windows
symbolic link - unknown type" would be enough to start the investigation into
the right direction.


--
With best regards,
Andrey Repin
Sunday, March 29, 2020 14:50:51

Sorry for my terrible english...

--
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
12