* WSL symbolic links @ 2020-03-26 9:00 Thomas Wolff 2020-03-26 11:00 ` Corinna Vinschen 0 siblings, 1 reply; 23+ messages in thread From: Thomas Wolff @ 2020-03-26 9:00 UTC (permalink / raw) To: cygwin 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-26 9:00 WSL symbolic links Thomas Wolff @ 2020-03-26 11:00 ` Corinna Vinschen 2020-03-26 16:15 ` Thomas Wolff ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Corinna Vinschen @ 2020-03-26 11:00 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-26 11:00 ` Corinna Vinschen @ 2020-03-26 16:15 ` Thomas Wolff 2020-03-26 19:12 ` Brian Inglis 2020-04-04 14:32 ` Denis Excoffier 2 siblings, 0 replies; 23+ messages in thread From: Thomas Wolff @ 2020-03-26 16:15 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-26 11:00 ` Corinna Vinschen 2020-03-26 16:15 ` Thomas Wolff @ 2020-03-26 19:12 ` Brian Inglis 2020-03-26 19:56 ` Corinna Vinschen 2020-03-26 20:05 ` Corinna Vinschen 2020-04-04 14:32 ` Denis Excoffier 2 siblings, 2 replies; 23+ messages in thread From: Brian Inglis @ 2020-03-26 19:12 UTC (permalink / raw) To: cygwin 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-26 19:12 ` Brian Inglis @ 2020-03-26 19:56 ` Corinna Vinschen 2020-03-26 23:52 ` Thomas Wolff 2020-03-26 20:05 ` Corinna Vinschen 1 sibling, 1 reply; 23+ messages in thread From: Corinna Vinschen @ 2020-03-26 19:56 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-26 19:56 ` Corinna Vinschen @ 2020-03-26 23:52 ` Thomas Wolff 2020-03-27 5:46 ` ASSI 2020-03-27 11:21 ` Corinna Vinschen 0 siblings, 2 replies; 23+ messages in thread From: Thomas Wolff @ 2020-03-26 23:52 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-26 23:52 ` Thomas Wolff @ 2020-03-27 5:46 ` ASSI 2020-03-27 11:21 ` Corinna Vinschen 1 sibling, 0 replies; 23+ messages in thread From: ASSI @ 2020-03-27 5:46 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-26 23:52 ` Thomas Wolff 2020-03-27 5:46 ` ASSI @ 2020-03-27 11:21 ` Corinna Vinschen 2020-03-27 12:24 ` Thomas Wolff 1 sibling, 1 reply; 23+ messages in thread From: Corinna Vinschen @ 2020-03-27 11:21 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-27 11:21 ` Corinna Vinschen @ 2020-03-27 12:24 ` Thomas Wolff 2020-03-27 13:01 ` Corinna Vinschen 0 siblings, 1 reply; 23+ messages in thread From: Thomas Wolff @ 2020-03-27 12:24 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-27 12:24 ` Thomas Wolff @ 2020-03-27 13:01 ` Corinna Vinschen 2020-03-27 14:43 ` Thomas Wolff 0 siblings, 1 reply; 23+ messages in thread From: Corinna Vinschen @ 2020-03-27 13:01 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-27 13:01 ` Corinna Vinschen @ 2020-03-27 14:43 ` Thomas Wolff 0 siblings, 0 replies; 23+ messages in thread From: Thomas Wolff @ 2020-03-27 14:43 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-26 19:12 ` Brian Inglis 2020-03-26 19:56 ` Corinna Vinschen @ 2020-03-26 20:05 ` Corinna Vinschen 2020-03-27 17:58 ` Brian Inglis 1 sibling, 1 reply; 23+ messages in thread From: Corinna Vinschen @ 2020-03-26 20:05 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-26 20:05 ` Corinna Vinschen @ 2020-03-27 17:58 ` Brian Inglis 2020-03-27 18:53 ` Corinna Vinschen 0 siblings, 1 reply; 23+ messages in thread From: Brian Inglis @ 2020-03-27 17:58 UTC (permalink / raw) To: cygwin [-- 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-27 17:58 ` Brian Inglis @ 2020-03-27 18:53 ` Corinna Vinschen 2020-03-28 3:32 ` Brian Inglis 0 siblings, 1 reply; 23+ messages in thread From: Corinna Vinschen @ 2020-03-27 18:53 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-27 18:53 ` Corinna Vinschen @ 2020-03-28 3:32 ` Brian Inglis 2020-03-28 10:31 ` Henry S. Thompson ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Brian Inglis @ 2020-03-28 3:32 UTC (permalink / raw) To: cygwin 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-28 3:32 ` Brian Inglis @ 2020-03-28 10:31 ` Henry S. Thompson 2020-03-28 11:30 ` Thomas Wolff 2020-03-28 11:59 ` Andrey Repin 2020-03-30 8:46 ` Corinna Vinschen 2 siblings, 1 reply; 23+ messages in thread From: Henry S. Thompson @ 2020-03-28 10:31 UTC (permalink / raw) To: 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 :-). 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-28 10:31 ` Henry S. Thompson @ 2020-03-28 11:30 ` Thomas Wolff 0 siblings, 0 replies; 23+ messages in thread From: Thomas Wolff @ 2020-03-28 11:30 UTC (permalink / raw) To: cygwin 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`? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-28 3:32 ` Brian Inglis 2020-03-28 10:31 ` Henry S. Thompson @ 2020-03-28 11:59 ` Andrey Repin 2020-03-28 20:45 ` Brian Inglis 2020-03-30 8:46 ` Corinna Vinschen 2 siblings, 1 reply; 23+ messages in thread From: Andrey Repin @ 2020-03-28 11:59 UTC (permalink / raw) To: Brian Inglis, cygwin 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... ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-28 11:59 ` Andrey Repin @ 2020-03-28 20:45 ` Brian Inglis 2020-03-29 11:52 ` Andrey Repin 0 siblings, 1 reply; 23+ messages in thread From: Brian Inglis @ 2020-03-28 20:45 UTC (permalink / raw) To: cygwin 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-28 20:45 ` Brian Inglis @ 2020-03-29 11:52 ` Andrey Repin 0 siblings, 0 replies; 23+ messages in thread From: Andrey Repin @ 2020-03-29 11:52 UTC (permalink / raw) To: Brian Inglis, cygwin 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... ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-28 3:32 ` Brian Inglis 2020-03-28 10:31 ` Henry S. Thompson 2020-03-28 11:59 ` Andrey Repin @ 2020-03-30 8:46 ` Corinna Vinschen 2 siblings, 0 replies; 23+ messages in thread From: Corinna Vinschen @ 2020-03-30 8:46 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-03-26 11:00 ` Corinna Vinschen 2020-03-26 16:15 ` Thomas Wolff 2020-03-26 19:12 ` Brian Inglis @ 2020-04-04 14:32 ` Denis Excoffier 2020-04-05 15:22 ` Corinna Vinschen 2 siblings, 1 reply; 23+ messages in thread From: Denis Excoffier @ 2020-04-04 14:32 UTC (permalink / raw) To: The Cygwin Mailing List; +Cc: Denis Excoffier, Corinna Vinschen 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: WSL symbolic links 2020-04-04 14:32 ` Denis Excoffier @ 2020-04-05 15:22 ` Corinna Vinschen 0 siblings, 0 replies; 23+ messages in thread From: Corinna Vinschen @ 2020-04-05 15:22 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2020-04-05 15:22 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-26 9:00 WSL symbolic links Thomas Wolff 2020-03-26 11:00 ` Corinna Vinschen 2020-03-26 16:15 ` Thomas Wolff 2020-03-26 19:12 ` Brian Inglis 2020-03-26 19:56 ` Corinna Vinschen 2020-03-26 23:52 ` Thomas Wolff 2020-03-27 5:46 ` ASSI 2020-03-27 11:21 ` Corinna Vinschen 2020-03-27 12:24 ` Thomas Wolff 2020-03-27 13:01 ` Corinna Vinschen 2020-03-27 14:43 ` Thomas Wolff 2020-03-26 20:05 ` Corinna Vinschen 2020-03-27 17:58 ` Brian Inglis 2020-03-27 18:53 ` Corinna Vinschen 2020-03-28 3:32 ` Brian Inglis 2020-03-28 10:31 ` Henry S. Thompson 2020-03-28 11:30 ` Thomas Wolff 2020-03-28 11:59 ` Andrey Repin 2020-03-28 20:45 ` Brian Inglis 2020-03-29 11:52 ` Andrey Repin 2020-03-30 8:46 ` Corinna Vinschen 2020-04-04 14:32 ` Denis Excoffier 2020-04-05 15:22 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).