WSL symbolic links

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.

Re: WSL symbolic links

[Corinna Vinschen]

[-- Attachment #1.1: Type: text/plain, Size: 823 bytes --]

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

[-- Attachment #1.2: rd-reparse.c --]
[-- Type: text/plain, Size: 3721 bytes --]

#include <stdio.h>
#include <wchar.h>
#include <windows.h>
#include <winternl.h>

typedef struct {
    DWORD  ReparseTag;
    WORD   ReparseDataLength;
    WORD   Reserved;
    union {
        struct {
            WORD   SubstituteNameOffset;
            WORD   SubstituteNameLength;
            WORD   PrintNameOffset;
            WORD   PrintNameLength;
	    DWORD  Flag;
            WCHAR PathBuffer[1];
        } SymbolicLinkReparseBuffer;
        struct {
            WORD   SubstituteNameOffset;
            WORD   SubstituteNameLength;
            WORD   PrintNameOffset;
            WORD   PrintNameLength;
            WCHAR PathBuffer[1];
        } MountPointReparseBuffer;
        struct {
            BYTE   DataBuffer[1];
        } GenericReparseBuffer;
    };
} MY_REPARSE_DATA_BUFFER, *MY_PREPARSE_DATA_BUFFER;

//ULONG WINAPI RtlCreateUnicodeStringFromAsciiz (PUNICODE_STRING, PCSTR);

int
main (int argc, char **argv)
{
  HANDLE fh;
  char buf[MAXIMUM_REPARSE_DATA_BUFFER_SIZE];
  DWORD siz;
  MY_PREPARSE_DATA_BUFFER rp;
  char *pbuf;
  char name[32768];
  NTSTATUS status;
  IO_STATUS_BLOCK io;
  UNICODE_STRING fname;
  OBJECT_ATTRIBUTES attr;

  RtlCreateUnicodeStringFromAsciiz (&fname, argv[1]);
  InitializeObjectAttributes(&attr, &fname, OBJ_CASE_INSENSITIVE, NULL, 0);
  status = NtOpenFile (&fh, FILE_READ_EA | FILE_READ_ATTRIBUTES | SYNCHRONIZE,
		       &attr, &io,
		       FILE_SHARE_VALID_FLAGS,
		       FILE_SYNCHRONOUS_IO_NONALERT
		       | FILE_OPEN_FOR_BACKUP_INTENT
		       | FILE_OPEN_REPARSE_POINT);
  if (!NT_SUCCESS (status))
    {
      fprintf (stderr, "NtOpenFile: %08X\n", status);
      return 1;
    }
  status = NtFsControlFile (fh, NULL, NULL, NULL, &io,
			    FSCTL_GET_REPARSE_POINT, NULL, 0,
			    (LPVOID) buf, sizeof buf);
  if (!NT_SUCCESS (status))
    {
      fprintf (stderr, "NtDeviceIoControlFile: %08lX\n", status);
      CloseHandle (fh);
      return 1;
    }

  rp = (MY_PREPARSE_DATA_BUFFER) buf;
  printf ("ReparseTag:           0x%08x\n", rp->ReparseTag);
  printf ("ReparseDataLength:    %10d\n", rp->ReparseDataLength);
  printf ("Reserved:             %10d\n", rp->Reserved);
  if (rp->ReparseTag == IO_REPARSE_TAG_SYMLINK
      || rp->ReparseTag == IO_REPARSE_TAG_SYMLINK)
    {
      printf ("SubstituteNameOffset: %10d\n",
	      rp->SymbolicLinkReparseBuffer.SubstituteNameOffset);
      printf ("SubstituteNameLength: %10d\n",
	      rp->SymbolicLinkReparseBuffer.SubstituteNameLength);
      printf ("PrintNameOffset:      %10d\n",
	      rp->SymbolicLinkReparseBuffer.PrintNameOffset);
      printf ("PrintNameLength:      %10d\n",
	      rp->SymbolicLinkReparseBuffer.PrintNameLength);
      if (rp->ReparseTag == IO_REPARSE_TAG_SYMLINK)
	{
	  printf ("Flag:                 0x%08x\n",
		  rp->SymbolicLinkReparseBuffer.Flag);
	  pbuf = (char *) rp->SymbolicLinkReparseBuffer.PathBuffer;
	}
      else
	pbuf = (char *) rp->MountPointReparseBuffer.PathBuffer;
      wcstombs (name,
		(PWCHAR) (pbuf + rp->SymbolicLinkReparseBuffer.SubstituteNameOffset),
		rp->SymbolicLinkReparseBuffer.SubstituteNameLength / 2);
      name[rp->SymbolicLinkReparseBuffer.SubstituteNameLength / 2] = '\0';
      printf("SubstituteName:       %s\n", name);
      wcstombs (name,
		(PWCHAR) (pbuf + rp->SymbolicLinkReparseBuffer.PrintNameOffset),
		rp->SymbolicLinkReparseBuffer.PrintNameLength / 2);
      name[rp->SymbolicLinkReparseBuffer.PrintNameLength / 2] = '\0';
      printf("PrintName:            %s\n", name);
    }
  else
    {
      WORD i;

      for (i = 0; i < rp->ReparseDataLength; ++i)
	{
	  printf ("%02x ", rp->GenericReparseBuffer.DataBuffer[i]);
	  if ((i + 1) % 16 == 0)
	    putchar ('\n');
	}
    }

  CloseHandle (fh);
  return 0;
}

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

Re: WSL symbolic links

[Brian Inglis]

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.

Re: WSL symbolic links

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2973 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: WSL symbolic links

[Thomas Wolff]

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

Re: WSL symbolic links

[ASSI]

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

Re: WSL symbolic links

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4113 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

Re: WSL symbolic links

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2941 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

Re: WSL symbolic links

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: WSL symbolic links

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 2313 bytes --]

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.

[-- Attachment #2: ls-l.strace.txt --]
[-- Type: text/plain, Size: 17600 bytes --]

--- Process 12772 created
--- Process 12772 loaded C:\Windows\System32\ntdll.dll at 00007ff9e9120000
--- Process 12772 loaded C:\Windows\System32\kernel32.dll at 00007ff9e7320000
--- Process 12772 loaded C:\Windows\System32\KernelBase.dll at 00007ff9e6d30000
--- Process 12772 thread 5544 created
--- Process 12772 thread 7184 created
--- Process 12772 loaded C:\...\cygwin64\bin\cygwin1.dll at 0000000180040000
--- Process 12772 loaded C:\...\cygwin64\bin\cygintl-8.dll at 00000003c49c0000
--- Process 12772 thread 15324 created
--- Process 12772 loaded C:\...\cygwin64\bin\cygiconv-2.dll at 00000003d72e0000
    0       0 [main] ls (12772) **********************************************
  274     274 [main] ls (12772) Program name: C:\...\cygwin64\bin\ls.exe (windows pid 12772)
   59     333 [main] ls (12772) OS version:   Windows NT-10.0
   61     394 [main] ls (12772) **********************************************
--- Process 12772 loaded C:\Windows\System32\advapi32.dll at 00007ff9e78e0000
--- Process 12772 loaded C:\Windows\System32\msvcrt.dll at 00007ff9e86d0000
--- Process 12772 loaded C:\Windows\System32\sechost.dll at 00007ff9e8a40000
--- Process 12772 loaded C:\Windows\System32\rpcrt4.dll at 00007ff9e8fc0000
--- Process 12772 loaded C:\Windows\System32\cryptbase.dll at 00007ff9e59c0000
--- Process 12772 loaded C:\Windows\System32\bcryptprimitives.dll at 00007ff9e6260000
...
 4047   83868 [main] ls 25955 lstat64: entering
   64   83932 [main] ls 25955 normalize_posix_path: src u
   42   83974 [main] ls 25955 cwdstuff::get: posix /home/$USER
   41   84015 [main] ls 25955 cwdstuff::get: (/home/$USER) = cwdstuff::get (0x800000010, 32768, 1, 0), errno 0
   42   84057 [main] ls 25955 normalize_posix_path: /home/$USER/u = normalize_posix_path (u)
   41   84098 [main] ls 25955 mount_info::conv_to_win32_path: conv_to_win32_path (/home/$USER/u)
   42   84140 [main] ls 25955 mount_info::cygdrive_win32_path: src '/home/$USER/u', dst 'C:\Users\$USER\u'
   43   84183 [main] ls 25955 mount_info::conv_to_win32_path: src_path /home/$USER/u, dst C:\Users\$USER\u, flags 0x4028, rc 0
  115   84298 [main] ls 25955 symlink_info::check: 0x0 = NtCreateFile (\??\C:\Users\$USER\u)
   93   84391 [main] ls 25955 symlink_info::check: not a symlink
   96   84487 [main] ls 25955 symlink_info::check: 0 = symlink.check(C:\Users\$USER\u, 0xFFFFB700) (mount_flags 0x4028, path_flags 0x0)
   53   84540 [main] ls 25955 path_conv::check: this->path(C:\Users\$USER\u), has_acls(1)
   47   84587 [main] ls 25955 build_fh_pc: fh 0x18034C1E0, dev 000000C3
   41   84628 [main] ls 25955 stat_worker: (\??\C:\Users\$USER\u, 0x8000986E0, 0x18034C1E0), file_attributes 32
   44   84672 [main] ls 25955 fhandler_base::open: (\??\C:\Users\$USER\u, 0x110000)
   69   84741 [main] ls 25955 seterrno_from_nt_status: /home/corinna/src/cygwin/cygwin-3.1.4/cygwin-3.1.4-1.x86_64/src/newlib-cygwin/winsup/cygwin/fhandler.cc:727 status 0xC0000279 -> windows error 1920
   43   84784 [main] ls 25955 geterrno_from_win_error: unknown windows error 1920, setting errno to 13
   41   84825 [main] ls 25955 fhandler_base::open: 0xC0000279 = NtCreateFile (0x3F3F5C28203A7265, 0x80100000, \??\C:\Users\$USER\u, io, NULL, 0x0, 0x7, 0x1, 0x4020, NULL, 0)
   41   84866 [main] ls 25955 fhandler_base::open: 0 = fhandler_base::open(\??\C:\Users\$USER\u, 0x110000)
   40   84906 [main] ls 25955 fhandler_base::open_fs: 0 = fhandler_disk_file::open(\??\C:\Users\$USER\u, 0x10000)
   41   84947 [main] ls 25955 fhandler_base::open: (\??\C:\Users\$USER\u, 0x110000)
   60   85007 [main] ls 25955 seterrno_from_nt_status: /home/corinna/src/cygwin/cygwin-3.1.4/cygwin-3.1.4-1.x86_64/src/newlib-cygwin/winsup/cygwin/fhandler.cc:727 status 0xC0000279 -> windows error 1920
   41   85048 [main] ls 25955 geterrno_from_win_error: unknown windows error 1920, setting errno to 13
   51   85099 [main] ls 25955 fhandler_base::open: 0xC0000279 = NtCreateFile (0x3F3F5C28203A7265, 0x20080, \??\C:\Users\$USER\u, io, NULL, 0x0, 0x7, 0x1, 0x4000, NULL, 0)
   48   85147 [main] ls 25955 fhandler_base::open: 0 = fhandler_base::open(\??\C:\Users\$USER\u, 0x110000)
   41   85188 [main] ls 25955 fhandler_base::open_fs: 0 = fhandler_disk_file::open(\??\C:\Users\$USER\u, 0x10000)
  217   85405 [main] ls 25955 seterrno_from_nt_status: /home/corinna/src/cygwin/cygwin-3.1.4/cygwin-3.1.4-1.x86_64/src/newlib-cygwin/winsup/cygwin/security.cc:72 status 0xC0000279 -> windows error 1920
   50   85455 [main] ls 25955 geterrno_from_win_error: unknown windows error 1920, setting errno to 13
   42   85497 [main] ls 25955 fhandler_base::fstat_helper: 0 = fstat (\??\C:\Users\$USER\u, 0x8000986E0) st_size=0, st_mode=0100640, st_ino=59954170039994494st_atim=5DC6BA91.204324A0 st_ctim=5E26616D.36B95128 st_mtim=5DC6BA91.204324A0 st_birthtim=59D47A24.2C0A6870
   44   85541 [main] ls 25955 stat_worker: 0 = (\??\C:\Users\$USER\u,0x8000986E0)
   47   85588 [main] ls 25955 normalize_posix_path: src u
   40   85628 [main] ls 25955 cwdstuff::get: posix /home/$USER
   42   85670 [main] ls 25955 cwdstuff::get: (/home/$USER) = cwdstuff::get (0x800000010, 32768, 1, 0), errno 0
   41   85711 [main] ls 25955 normalize_posix_path: /home/$USER/u = normalize_posix_path (u)
   40   85751 [main] ls 25955 mount_info::conv_to_win32_path: conv_to_win32_path (/home/$USER/u)
   42   85793 [main] ls 25955 mount_info::cygdrive_win32_path: src '/home/$USER/u', dst 'C:\Users\$USER\u'
   41   85834 [main] ls 25955 mount_info::conv_to_win32_path: src_path /home/$USER/u, dst C:\Users\$USER\u, flags 0x4028, rc 0
   64   85898 [main] ls 25955 symlink_info::check: 0x0 = NtCreateFile (\??\C:\Users\$USER\u)
   71   85969 [main] ls 25955 symlink_info::check: not a symlink
   60   86029 [main] ls 25955 symlink_info::check: 0 = symlink.check(C:\Users\$USER\u, 0xFFFFB6D0) (mount_flags 0x4028, path_flags 0x0)
   41   86070 [main] ls 25955 path_conv::check: this->path(C:\Users\$USER\u), has_acls(1)
   44   86114 [main] ls 25955 build_fh_pc: fh 0x18034C1E0, dev 000000C3
   42   86156 [main] ls 25955 fhandler_base::open: (\??\C:\Users\$USER\u, 0x110000)
   58   86214 [main] ls 25955 seterrno_from_nt_status: /home/corinna/src/cygwin/cygwin-3.1.4/cygwin-3.1.4-1.x86_64/src/newlib-cygwin/winsup/cygwin/fhandler.cc:727 status 0xC0000279 -> windows error 1920
   42   86256 [main] ls 25955 geterrno_from_win_error: unknown windows error 1920, setting errno to 13
   40   86296 [main] ls 25955 fhandler_base::open: 0xC0000279 = NtCreateFile (0x30, 0x20000, \??\C:\Users\$USER\u, io, NULL, 0x0, 0x7, 0x1, 0x4000, NULL, 0)
   43   86339 [main] ls 25955 fhandler_base::open: 0 = fhandler_base::open(\??\C:\Users\$USER\u, 0x110000)
   47   86386 [main] ls 25955 fhandler_base::open_fs: 0 = fhandler_disk_file::open(\??\C:\Users\$USER\u, 0x10000)
   85   86471 [main] ls 25955 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\cygwin-f031669020b3f992-lpc
  323   86794 [main] ls 25955 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\cygwin-f031669020b3f992-lpc
  341   87135 [main] ls 25955 time: 1585329297 = time(0x0)
   42   87177 [main] ls 25955 stat64: entering
   42   87219 [main] ls 25955 normalize_posix_path: src /dev
   40   87259 [main] ls 25955 normalize_posix_path: /dev = normalize_posix_path (/dev)
   41   87300 [main] ls 25955 mount_info::conv_to_win32_path: conv_to_win32_path (/dev)
   53   87353 [main] ls 25955 mount_info::conv_to_win32_path: src_path /dev, dst C:\...\cygwin64\dev, flags 0x30008, rc 0
   82   87435 [main] ls 25955 symlink_info::check: 0x0 = NtCreateFile (\??\C:\...\cygwin64\dev)
   58   87493 [main] ls 25955 symlink_info::check: not a symlink
   42   87535 [main] ls 25955 symlink_info::check: 0 = symlink.check(C:\...\cygwin64\dev, 0xFFFFA670) (mount_flags 0x30008, path_flags 0x0)
   47   87582 [main] ls 25955 build_fh_pc: fh 0x18034C1E0, dev 000000C1
   42   87624 [main] ls 25955 stat_worker: (\??\C:\...\cygwin64\dev, 0x180320C40, 0x18034C1E0), file_attributes 16
  121   87745 [main] ls 25955 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\cygwin-f031669020b3f992-lpc
  273   88018 [main] ls 25955 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\cygwin-f031669020b3f992-lpc
  249   88267 [main] ls 25955 fhandler_base::fstat_helper: 0 = fstat (\??\C:\...\cygwin64\dev, 0x180320C40) st_size=0, st_mode=040775, st_ino=281474977203754st_atim=5E72D5F5.137D3CEC st_ctim=5E72D5F5.137D3CEC st_mtim=5E72D5F5.137D3CEC st_birthtim=5193096A.12A4EDEC
  101   88368 [main] ls 25955 stat_worker: 0 = (\??\C:\...\cygwin64\dev,0x180320C40)
  112   88480 [main] ls 25955 fstat64: 0 = fstat(1, 0xFFFFB9C0)
   88   88568 [main] ls 25955 isatty: 1 = isatty(1)
  197   88765 [main] ls 25955 open: open(/usr/share/zoneinfo/$TZ, 0x10000)
   48   88813 [main] ls 25955 normalize_posix_path: src /usr/share/zoneinfo/$TZ
   95   88908 [main] ls 25955 normalize_posix_path: /usr/share/zoneinfo/$TZ = normalize_posix_path (/usr/share/zoneinfo/$TZ)
   61   88969 [main] ls 25955 mount_info::conv_to_win32_path: conv_to_win32_path (/usr/share/zoneinfo/$TZ)
   63   89032 [main] ls 25955 mount_info::conv_to_win32_path: src_path /usr/share/zoneinfo/$TZ, dst C:\...\cygwin64\usr\share\zoneinfo\$TZ, flags 0x30008, rc 0
  114   89146 [main] ls 25955 symlink_info::check: 0xC000003A = NtCreateFile (\??\C:\...\cygwin64\usr\share\zoneinfo\$TZ)
   48   89194 [main] ls 25955 symlink_info::check: 0xC000003A = NtQueryInformationFile (\??\C:\...\cygwin64\usr\share\zoneinfo\$TZ)
   44   89238 [main] ls 25955 symlink_info::check: not a symlink
   54   89292 [main] ls 25955 symlink_info::check: 0 = symlink.check(C:\...\cygwin64\usr\share\zoneinfo\$TZ, 0xFFFF5F50) (mount_flags 0x30008, path_flags 0x0)
   63   89355 [main] ls 25955 mount_info::conv_to_win32_path: conv_to_win32_path (/usr/share/zoneinfo/America)
   58   89413 [main] ls 25955 mount_info::conv_to_win32_path: src_path /usr/share/zoneinfo/America, dst C:\...\cygwin64\usr\share\zoneinfo\America, flags 0x30008, rc 0
  101   89514 [main] ls 25955 symlink_info::check: 0x0 = NtCreateFile (\??\C:\...\cygwin64\usr\share\zoneinfo\America)
  269   89783 [main] ls 25955 symlink_info::check: 13 = symlink.check(C:\...\cygwin64\usr\share\zoneinfo\America, 0xFFFF5F50) (mount_flags 0x30008, path_flags 0x10)
   55   89838 [main] ls 25955 normalize_posix_path: src /usr/share/zoneinfo/posix/$TZ
   49   89887 [main] ls 25955 normalize_posix_path: /usr/share/zoneinfo/posix/$TZ = normalize_posix_path (/usr/share/zoneinfo/posix/$TZ)
   50   89937 [main] ls 25955 mount_info::conv_to_win32_path: conv_to_win32_path (/usr/share/zoneinfo/posix/$TZ)
   67   90004 [main] ls 25955 mount_info::conv_to_win32_path: src_path /usr/share/zoneinfo/posix/$TZ, dst C:\...\cygwin64\usr\share\zoneinfo\posix\$TZ, flags 0x30008, rc 0
  134   90138 [main] ls 25955 symlink_info::check: 0x0 = NtCreateFile (\??\C:\...\cygwin64\usr\share\zoneinfo\posix\$TZ)
   82   90220 [main] ls 25955 symlink_info::check: not a symlink
   92   90312 [main] ls 25955 symlink_info::check: 0 = symlink.check(C:\...\cygwin64\usr\share\zoneinfo\posix\$TZ, 0xFFFF5F50) (mount_flags 0x30008, path_flags 0x0)
   74   90386 [main] ls 25955 path_conv::check: this->path(C:\...\cygwin64\usr\share\zoneinfo\posix\$TZ), has_acls(1)
   53   90439 [main] ls 25955 build_fh_pc: fh 0x18034C1E0, dev 000000C3
   48   90487 [main] ls 25955 fhandler_base::open: (\??\C:\...\cygwin64\usr\share\zoneinfo\posix\$TZ, 0x118000)
  156   90643 [main] ls 25955 fhandler_base::set_flags: flags 0x118000, supplied_bin 0x10000
   52   90695 [main] ls 25955 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x10000
   53   90748 [main] ls 25955 fhandler_base::set_flags: filemode set to binary
   47   90795 [main] ls 25955 fhandler_base::open: 0x0 = NtCreateFile (0x1F0, 0x80100000, \??\C:\...\cygwin64\usr\share\zoneinfo\posix\$TZ, io, NULL, 0x0, 0x7, 0x1, 0x4020, NULL, 0)
   42   90837 [main] ls 25955 fhandler_base::open: 1 = fhandler_base::open(\??\C:\...\cygwin64\usr\share\zoneinfo\posix\$TZ, 0x118000)
   40   90877 [main] ls 25955 fhandler_base::open_fs: 1 = fhandler_disk_file::open(\??\C:\...\cygwin64\usr\share\zoneinfo\posix\$TZ, 0x18000)
   43   90920 [main] ls 25955 open: 3 = open(/usr/share/zoneinfo/$TZ, 0x18000)
   43   90963 [main] ls 25955 read: read(3, 0x8000A9830, 41448) blocking
   96   91059 [main] ls 25955 fhandler_base::read: returning 2332, binary mode
   47   91106 [main] ls 25955 read: 2332 = read(3, 0x8000A9830, 2332)
   43   91149 [main] ls 25955 close: close(3)
   42   91191 [main] ls 25955 fhandler_base::close: closing '/usr/share/zoneinfo/posix/$TZ' handle 0x1F0
   73   91264 [main] ls 25955 close: 0 = close(3)
  120   91384 [main] ls 25955 open: open(/usr/share/zoneinfo/posixrules, 0x10000)
   55   91439 [main] ls 25955 normalize_posix_path: src /usr/share/zoneinfo/posixrules
   42   91481 [main] ls 25955 normalize_posix_path: /usr/share/zoneinfo/posixrules = normalize_posix_path (/usr/share/zoneinfo/posixrules)
   43   91524 [main] ls 25955 mount_info::conv_to_win32_path: conv_to_win32_path (/usr/share/zoneinfo/posixrules)
   42   91566 [main] ls 25955 mount_info::conv_to_win32_path: src_path /usr/share/zoneinfo/posixrules, dst C:\...\cygwin64\usr\share\zoneinfo\posixrules, flags 0x30008, rc 0
   80   91646 [main] ls 25955 symlink_info::check: 0x0 = NtCreateFile (\??\C:\...\cygwin64\usr\share\zoneinfo\posixrules)
   64   91710 [main] ls 25955 symlink_info::check: not a symlink
   65   91775 [main] ls 25955 symlink_info::check: 0 = symlink.check(C:\...\cygwin64\usr\share\zoneinfo\posixrules, 0xFFFF15D0) (mount_flags 0x30008, path_flags 0x0)
   42   91817 [main] ls 25955 path_conv::check: this->path(C:\...\cygwin64\usr\share\zoneinfo\posixrules), has_acls(1)
   45   91862 [main] ls 25955 build_fh_pc: fh 0x18034C1E0, dev 000000C3
   43   91905 [main] ls 25955 fhandler_base::open: (\??\C:\...\cygwin64\usr\share\zoneinfo\posixrules, 0x118000)
   92   91997 [main] ls 25955 fhandler_base::set_flags: flags 0x118000, supplied_bin 0x10000
   46   92043 [main] ls 25955 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x10000
   45   92088 [main] ls 25955 fhandler_base::set_flags: filemode set to binary
   44   92132 [main] ls 25955 fhandler_base::open: 0x0 = NtCreateFile (0x1F0, 0x80100000, \??\C:\...\cygwin64\usr\share\zoneinfo\posixrules, io, NULL, 0x0, 0x7, 0x1, 0x4020, NULL, 0)
   46   92178 [main] ls 25955 fhandler_base::open: 1 = fhandler_base::open(\??\C:\...\cygwin64\usr\share\zoneinfo\posixrules, 0x118000)
   56   92234 [main] ls 25955 fhandler_base::open_fs: 1 = fhandler_disk_file::open(\??\C:\...\cygwin64\usr\share\zoneinfo\posixrules, 0x18000)
   48   92282 [main] ls 25955 open: 3 = open(/usr/share/zoneinfo/posixrules, 0x18000)
   78   92360 [main] ls 25955 read: read(3, 0x8000B3A20, 41448) blocking
   94   92454 [main] ls 25955 fhandler_base::read: returning 3536, binary mode
   43   92497 [main] ls 25955 read: 3536 = read(3, 0x8000B3A20, 3536)
   40   92537 [main] ls 25955 close: close(3)
   40   92577 [main] ls 25955 fhandler_base::close: closing '/usr/share/zoneinfo/posixrules' handle 0x1F0
   62   92639 [main] ls 25955 close: 0 = close(3)
 1549   94188 [main] ls 25955 fhandler_console::write: 0x8000767E0, 57
  406   94594 [main] ls 25955 fhandler_console::write: 57 = fhandler_console::write(...)
  389   94983 [main] ls 25955 write: 57 = write(1, 0x8000767E0, 57)
  296   95279 [main] ls 25955 close: close(1)
   42   95321 [main] ls 25955 fhandler_base::close_with_arch: line 1183:  /dev/cons0<0x18034B3F0> usecount + -1 = 3
   41   95362 [main] ls 25955 fhandler_base::close_with_arch: not closing archetype
  121   95483 [main] ls 25955 close: 0 = close(1)
  473   95956 [main] ls 25955 close: close(2)
   42   95998 [main] ls 25955 fhandler_base::close_with_arch: line 1183:  /dev/cons0<0x18034B3F0> usecount + -1 = 2
   42   96040 [main] ls 25955 fhandler_base::close_with_arch: not closing archetype
   41   96081 [main] ls 25955 close: 0 = close(2)
  351   96432 [main] ls 25955 do_exit: do_exit (0), exit_state 1
   41   96473 [main] ls 25955 void: 0x0 = signal (20, 0x1)
   39   96512 [main] ls 25955 void: 0x0 = signal (1, 0x1)
   41   96553 [main] ls 25955 void: 0x0 = signal (2, 0x1)
   40   96593 [main] ls 25955 void: 0x0 = signal (3, 0x1)
   51   96644 [main] ls 25955 fhandler_base::close_with_arch: line 1183:  /dev/cons0<0x18034B3F0> usecount + -1 = 1
   42   96686 [main] ls 25955 fhandler_base::close_with_arch: not closing archetype
   43   96729 [main] ls 25955 init_cygheap::close_ctty: closing cygheap->ctty 0x18034B3F0
   41   96770 [main] ls 25955 fhandler_base::close_with_arch: closing passed in archetype 0x0, usecount 0
   41   96811 [main] ls 25955 fhandler_console::close: closing: 0x13C, 0x140
  248   97059 [main] ls 25955 fhandler_console::free_console: freed console, res 1
  231   97290 [main] ls 25955 dtable::delete_archetype: deleting element 0 for /dev/cons0(3/0)
   53   97343 [main] ls 25955 getpid: 25955 = getpid()
   44   97387 [main] ls 25955 proc_terminate: nprocs 0
   45   97432 [main] ls 25955 proc_terminate: leaving
   47   97479 [main] ls 25955 pinfo::exit: Calling dlls.cleanup_forkables n 0x0, exitcode 0x0
   47   97526 [main] ls 25955 pinfo::exit: Calling ExitProcess n 0x0, exitcode 0x0
--- Process 12772 (pid: 25955) thread 13188 exited with status 0x0
--- Process 12772 (pid: 25955) thread 13352 exited with status 0x0
--- Process 12772 (pid: 25955) thread 5544 exited with status 0x0
--- Process 12772 (pid: 25955) thread 15324 exited with status 0x0
--- Process 12772 (pid: 25955) exited with status 0x0

Re: WSL symbolic links

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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.

Re: WSL symbolic links

[Henry S. Thompson]

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: ht@inf.ed.ac.uk
                       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.

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

Re: WSL symbolic links

[Andrey Repin]

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

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.

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

Re: WSL symbolic links

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]

On Mar 27 21:32, Brian Inglis wrote:
> 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:
> >>>> 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.

Do you actually talk about my test source I sent in this thread?
It's just a very bare printer for the content of a reparse point
and has the flexibility factor of a hammer for electronic repairs.

If you like to use it as a base for something you outline above,
feel free.  The source can go into public domain, for all it's
worth.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: WSL symbolic links

[Denis Excoffier]

Hello,

I tried the last snapshot (not announced) dated 20200403, and the new symbolic links don’t seem to work properly:


% mkdir test
% cd test
% mkdir foo
% cp /usr/bin/ls.exe foo/ls.exe
% foo/ls
foo
% foo/ls.exe
foo
% ln -s foo bar
% bar/ls
bar/ls: Permission denied.
% bar/ls.exe
bar/ls.exe: Permission denied.
%

I’m on Windows 7, on a ntfs disk (binary,posix=0,user,nomount,auto).

Regards,

Denis Excoffier.

Re: WSL symbolic links

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

On Apr  4 16:32, Denis Excoffier wrote:
> Hello,
> 
> I tried the last snapshot (not announced) dated 20200403, and the new symbolic links don’t seem to work properly:
> 
> 
> % mkdir test
> % cd test
> % mkdir foo
> % cp /usr/bin/ls.exe foo/ls.exe
> % foo/ls
> foo
> % foo/ls.exe
> foo
> % ln -s foo bar
> % bar/ls
> bar/ls: Permission denied.
> % bar/ls.exe
> bar/ls.exe: Permission denied.
> %

Thanks, should be fixed in the latest snapshot.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]