Re: Mounted Network Drives generate "Too many levels of symbolic links"
Thanks everyone for your help and advice. I bit the bullet and uninstalled and re-installed cygwin, and now my network drives can be accessed from /cygdrive. - Beth --- Original Message --- On Wednesday, May 24th, 2023 at 4:23 PM, Marco Atzeri via Cygwin wrote: > On 24/05/2023 20:53, Takashi Yano via Cygwin wrote: > > > On Tue, 23 May 2023 13:11:42 + > > Beth Kirschner wrote: > > > > > Cygwin DLL version info: > > > DLL version: 3.3.4 > > > DLL epoch: 19 > > > DLL old termios: 5 > > > DLL malloc env: 28 > > > Cygwin conv: 181 > > > API major: 0 > > > API minor: 341 > > > Shared data: 5 > > > DLL identifier: cygwin1 > > > Mount registry: 3 > > > Cygwin registry name: Cygwin > > > Installations name: Installations > > > Cygdrive default prefix: > > > Build date: > > > Shared id: cygwin1S5 > > > Your cygcheck.out says you are using cygwin 3.3.4. > > > What does 'uname -a' says? > > > Beth, > this likely was caused by an upgrade with processes still running > > Check also if you have any file in /usr/bin/ with *.new name as also > those packages > > will require a re-installation > > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation: https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mounted Network Drives generate "Too many levels of symbolic links"
On 24/05/2023 20:53, Takashi Yano via Cygwin wrote: On Tue, 23 May 2023 13:11:42 + Beth Kirschner wrote: Cygwin DLL version info: DLL version: 3.3.4 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 341 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 Your cygcheck.out says you are using cygwin 3.3.4. What does 'uname -a' says? Beth, this likely was caused by an upgrade with processes still running Check also if you have any file in /usr/bin/ with *.new name as also those packages will require a re-installation -- 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: Mounted Network Drives generate "Too many levels of symbolic links"
On Tue, 23 May 2023 13:11:42 + Beth Kirschner wrote: > Cygwin DLL version info: > DLL version: 3.3.4 > DLL epoch: 19 > DLL old termios: 5 > DLL malloc env: 28 > Cygwin conv: 181 > API major: 0 > API minor: 341 > Shared data: 5 > DLL identifier: cygwin1 > Mount registry: 3 > Cygwin registry name: Cygwin > Installations name: Installations > Cygdrive default prefix: > Build date: > Shared id: cygwin1S5 Your cygcheck.out says you are using cygwin 3.3.4. What does 'uname -a' says? -- Takashi Yano -- 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: Mounted Network Drives generate "Too many levels of symbolic links"
On Wed, 24 May 2023 17:41:24 + Beth Kirschner wrote: > I've attached the Get-SmbConnection & 'net use' output - does this provide > any clues? net-use.txt: > New connections will not be remembered. > > > Status Local RemoteNetwork > > --- > J:\\urrea.local\NetScanner Microsoft Windows Network > O:\\urrea.local\operations Microsoft Windows Network > Q:\\urrea.local\arbor Microsoft Windows Network > R:\\urrea.local\PCR Microsoft Windows Network > S:\\urrea.local\Shared Microsoft Windows Network > U:\\urrea.local\DOPPS Microsoft Windows Network > V:\\urrea.local\Omics Microsoft Windows Network > X:\\urrea.local\Tx-DCC Microsoft Windows Network > The command completed successfully. There is no 'OK' on Status column and empty output from Get-SmbConnection. Is drive Q: really accessible? Can you open drive Q: using explorer? Doesn't 'dir Q:' in command prompt cause any error? -- Takashi Yano -- 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: Mounted Network Drives generate "Too many levels of symbolic links"
I've attached the Get-SmbConnection & 'net use' output - does this provide any
clues?
Thanks!
- Beth
--- Original Message ---
On Tuesday, May 23rd, 2023 at 6:27 PM, Takashi Yano
wrote:
> On Wed, 24 May 2023 07:23:27 +0900
> Takashi Yano wrote:
>
> > On Tue, 23 May 2023 13:11:42 +
> > Beth Kirschner wrote:
> >
> > > I can no longer access mounted network drives and receive the following
> > > error: "Too many levels of symbolic links". Local drives (C:) work fine.
> > >
> > > I believe the problem started after upgrading to Windows 11. I've updated
> > > my cygwin packages and attached output from cygcheck, plus some
> > > additional details below. Any ideas?
> > >
> > > $ mount
> > > C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
> > > C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
> > > C:/cygwin64 on / type ntfs (binary,auto)
> > > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> > > J: on /cygdrive/j type ntfs (binary,posix=0,user,noumount,auto)
> > > O: on /cygdrive/o type ntfs (binary,posix=0,user,noumount,auto)
> > > Q: on /cygdrive/q type ntfs (binary,posix=0,user,noumount,auto)
> > > R: on /cygdrive/r type ntfs (binary,posix=0,user,noumount,auto)
> > > S: on /cygdrive/s type ntfs (binary,posix=0,user,noumount,auto)
> > > U: on /cygdrive/u type ntfs (binary,posix=0,user,noumount,auto)
> > > V: on /cygdrive/v type ntfs (binary,posix=0,user,noumount,auto)
> > > X: on /cygdrive/x type ntfs (binary,posix=0,user,noumount,auto)
> > >
> > > bkirschner@LAP123 ~
> > > $ ls /cygdrive/q
> > > ls: cannot open directory '/cygdrive/q': Too many levels of symbolic links
> >
> > What does Get-SmbConnection command say in PowerShell running
> > as Administrator?
>
>
> Also, what does 'net use' command say in command prompt running
> as your user account?
>
> --
> Takashi Yano takashi.y...@nifty.ne.jpNew connections will not be remembered.
Status Local RemoteNetwork
---
J:\\urrea.local\NetScanner Microsoft Windows Network
O:\\urrea.local\operations Microsoft Windows Network
Q:\\urrea.local\arbor Microsoft Windows Network
R:\\urrea.local\PCR Microsoft Windows Network
S:\\urrea.local\Shared Microsoft Windows Network
U:\\urrea.local\DOPPS Microsoft Windows Network
V:\\urrea.local\Omics Microsoft Windows Network
X:\\urrea.local\Tx-DCC Microsoft Windows Network
The command completed successfully.
ÿþ
S e r v e r N a m e S h a r e N a m e U s e r N a m e
C r e d e n t i a l D i a l e c t
N u m O p e n s
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - -
- - - - - - - -
S V R 5 6 . u r r e a . l o c a l A r b o r
U R R E A \ b k i r s c h n e r U R R E A . L O C A L \ b k i r s c h n e r
3 . 1 . 1 1 4
S V R 5 6 . u r r e a . l o c a l D O P P S
U R R E A \ b k i r s c h n e r U R R E A . L O C A L \ b k i r s c h n e r
3 . 1 . 1 1
S V R 5 6 . u r r e a . l o c a l N e t S c a n n e r
U R R E A \ b k i r s c h n e r U R R E A . L O C A L \ b k i r s c h n e r
3 . 1 . 1 1
S V R 5 6 . u r r e a . l o c a l O m i c s
U R R E A \ b k i r s c h n e r U R R E A . L O C A L \ b k i r s c h n e r
3 . 1 . 1 1
S V R 5 6 . u r r e a . l o c a l O p e r a t i o n s
U R R E A \ b k i r s c h n e r U R R E A . L O C A L \ b k i r s c h n e r
3 . 1 . 1 1
S V R 5 6 . u r r e a . l o c a l P C R
U R R E A \ b k i r s c h n e r U R R E A . L O C A L \ b k i r s c h n e r
3 . 1 . 1 1
S V R 5 6 . u r r e a . l o c a l S h a r e d
U R R E A \ b k i r s c h n e r U R R E A . L O C A L \ b k i r s c h n e r
3 . 1 . 1 1
S V R 5 6 . u r r e a . l o c a l T x - D C C
U R R E A \ b k i r s c h n e r U R R E A . L O C A L \ b k i r s c h n e r
3 . 1 . 1 2
--
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: Mounted Network Drives generate "Too many levels of symbolic links"
On Wed, 24 May 2023 07:23:27 +0900 Takashi Yano wrote: > On Tue, 23 May 2023 13:11:42 + > Beth Kirschner wrote: > > I can no longer access mounted network drives and receive the following > > error: "Too many levels of symbolic links". Local drives (C:) work fine. > > > > I believe the problem started after upgrading to Windows 11. I've updated > > my cygwin packages and attached output from cygcheck, plus some additional > > details below. Any ideas? > > > > $ mount > > C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) > > C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) > > C:/cygwin64 on / type ntfs (binary,auto) > > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > > J: on /cygdrive/j type ntfs (binary,posix=0,user,noumount,auto) > > O: on /cygdrive/o type ntfs (binary,posix=0,user,noumount,auto) > > Q: on /cygdrive/q type ntfs (binary,posix=0,user,noumount,auto) > > R: on /cygdrive/r type ntfs (binary,posix=0,user,noumount,auto) > > S: on /cygdrive/s type ntfs (binary,posix=0,user,noumount,auto) > > U: on /cygdrive/u type ntfs (binary,posix=0,user,noumount,auto) > > V: on /cygdrive/v type ntfs (binary,posix=0,user,noumount,auto) > > X: on /cygdrive/x type ntfs (binary,posix=0,user,noumount,auto) > > > > bkirschner@LAP123 ~ > > $ ls /cygdrive/q > > ls: cannot open directory '/cygdrive/q': Too many levels of symbolic links > > What does Get-SmbConnection command say in PowerShell running > as Administrator? Also, what does 'net use' command say in command prompt running as your user account? -- Takashi Yano -- 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: Mounted Network Drives generate "Too many levels of symbolic links"
On Tue, 23 May 2023 13:11:42 + Beth Kirschner wrote: > I can no longer access mounted network drives and receive the following > error: "Too many levels of symbolic links". Local drives (C:) work fine. > > I believe the problem started after upgrading to Windows 11. I've updated my > cygwin packages and attached output from cygcheck, plus some additional > details below. Any ideas? > > $ mount > C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) > C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) > C:/cygwin64 on / type ntfs (binary,auto) > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > J: on /cygdrive/j type ntfs (binary,posix=0,user,noumount,auto) > O: on /cygdrive/o type ntfs (binary,posix=0,user,noumount,auto) > Q: on /cygdrive/q type ntfs (binary,posix=0,user,noumount,auto) > R: on /cygdrive/r type ntfs (binary,posix=0,user,noumount,auto) > S: on /cygdrive/s type ntfs (binary,posix=0,user,noumount,auto) > U: on /cygdrive/u type ntfs (binary,posix=0,user,noumount,auto) > V: on /cygdrive/v type ntfs (binary,posix=0,user,noumount,auto) > X: on /cygdrive/x type ntfs (binary,posix=0,user,noumount,auto) > > bkirschner@LAP123 ~ > $ ls /cygdrive/q > ls: cannot open directory '/cygdrive/q': Too many levels of symbolic links What does Get-SmbConnection command say in PowerShell running as Administrator? -- Takashi Yano -- 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
Mounted Network Drives generate "Too many levels of symbolic links"
I can no longer access mounted network drives and receive the following error: "Too many levels of symbolic links". Local drives (C:) work fine. I believe the problem started after upgrading to Windows 11. I've updated my cygwin packages and attached output from cygcheck, plus some additional details below. Any ideas? $ mount C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) C:/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) J: on /cygdrive/j type ntfs (binary,posix=0,user,noumount,auto) O: on /cygdrive/o type ntfs (binary,posix=0,user,noumount,auto) Q: on /cygdrive/q type ntfs (binary,posix=0,user,noumount,auto) R: on /cygdrive/r type ntfs (binary,posix=0,user,noumount,auto) S: on /cygdrive/s type ntfs (binary,posix=0,user,noumount,auto) U: on /cygdrive/u type ntfs (binary,posix=0,user,noumount,auto) V: on /cygdrive/v type ntfs (binary,posix=0,user,noumount,auto) X: on /cygdrive/x type ntfs (binary,posix=0,user,noumount,auto) bkirschner@LAP123 ~ $ ls /cygdrive/q ls: cannot open directory '/cygdrive/q': Too many levels of symbolic links cygcheck.out Description: Binary data -- 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: bash: cd: /cygdrive/w: Too many levels of symbolic links
On Fri, 29 Apr 2022 18:27:45 -0500 Wes Barris wrote: > On 4/29/2022 6:09 PM, Takashi Yano wrote: > > On Fri, 29 Apr 2022 14:21:01 -0500 > > Wes Barris wrote: > >> For the past couple of months the latest versions of cygwin produce this > >> error > >> when attempting to reference a network drive. There have been a couple of > >> other > >> threads reporting this and talk about patches. Is there a fix coming for > >> this > >> in the production version of cygwin? > >> > >> $ cd /cygdrive/w > >> bash: cd: /cygdrive/w: Too many levels of symbolic links > >> $ mount > >> C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) > >> C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) > >> C:/cygwin64 on / type ntfs (binary,auto) > >> C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) > >> D: on /cygdrive/d type ntfs (binary,noacl,posix=0,user,noumount,auto) > >> M: on /cygdrive/m type ntfs (binary,noacl,posix=0,user,noumount,auto) > >> P: on /cygdrive/p type ntfs (binary,noacl,posix=0,user,noumount,auto) > >> S: on /cygdrive/s type ntfs (binary,noacl,posix=0,user,noumount,auto) > >> V: on /cygdrive/v type ntfs (binary,noacl,posix=0,user,noumount,auto) > >> W: on /cygdrive/w type ntfs (binary,noacl,posix=0,user,noumount,auto) > > > > https://cygwin.com/pipermail/cygwin/2022-April/251332.html > > > > Thanks. Yes, that post describes what is happening to me. Is there a fix > coming for this? We are planning to release cygwin 3.3.5 in which the issue has been fixed soon after a few ongoing issues will be settled. -- Takashi Yano -- 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: bash: cd: /cygdrive/w: Too many levels of symbolic links
On 4/29/2022 6:09 PM, Takashi Yano wrote: On Fri, 29 Apr 2022 14:21:01 -0500 Wes Barris wrote: For the past couple of months the latest versions of cygwin produce this error when attempting to reference a network drive. There have been a couple of other threads reporting this and talk about patches. Is there a fix coming for this in the production version of cygwin? $ cd /cygdrive/w bash: cd: /cygdrive/w: Too many levels of symbolic links $ mount C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) C:/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,noacl,posix=0,user,noumount,auto) M: on /cygdrive/m type ntfs (binary,noacl,posix=0,user,noumount,auto) P: on /cygdrive/p type ntfs (binary,noacl,posix=0,user,noumount,auto) S: on /cygdrive/s type ntfs (binary,noacl,posix=0,user,noumount,auto) V: on /cygdrive/v type ntfs (binary,noacl,posix=0,user,noumount,auto) W: on /cygdrive/w type ntfs (binary,noacl,posix=0,user,noumount,auto) https://cygwin.com/pipermail/cygwin/2022-April/251332.html Thanks. Yes, that post describes what is happening to me. Is there a fix coming for this? -- Wes Barris -- This email has been checked for viruses by AVG. https://www.avg.com -- 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: bash: cd: /cygdrive/w: Too many levels of symbolic links
On Fri, 29 Apr 2022 14:21:01 -0500 Wes Barris wrote: > For the past couple of months the latest versions of cygwin produce this > error > when attempting to reference a network drive. There have been a couple of > other > threads reporting this and talk about patches. Is there a fix coming for > this > in the production version of cygwin? > > $ cd /cygdrive/w > bash: cd: /cygdrive/w: Too many levels of symbolic links > $ mount > C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) > C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) > C:/cygwin64 on / type ntfs (binary,auto) > C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) > D: on /cygdrive/d type ntfs (binary,noacl,posix=0,user,noumount,auto) > M: on /cygdrive/m type ntfs (binary,noacl,posix=0,user,noumount,auto) > P: on /cygdrive/p type ntfs (binary,noacl,posix=0,user,noumount,auto) > S: on /cygdrive/s type ntfs (binary,noacl,posix=0,user,noumount,auto) > V: on /cygdrive/v type ntfs (binary,noacl,posix=0,user,noumount,auto) > W: on /cygdrive/w type ntfs (binary,noacl,posix=0,user,noumount,auto) https://cygwin.com/pipermail/cygwin/2022-April/251332.html -- Takashi Yano -- 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
bash: cd: /cygdrive/w: Too many levels of symbolic links
For the past couple of months the latest versions of cygwin produce this error when attempting to reference a network drive. There have been a couple of other threads reporting this and talk about patches. Is there a fix coming for this in the production version of cygwin? $ cd /cygdrive/w bash: cd: /cygdrive/w: Too many levels of symbolic links $ mount C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) C:/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,noacl,posix=0,user,noumount,auto) M: on /cygdrive/m type ntfs (binary,noacl,posix=0,user,noumount,auto) P: on /cygdrive/p type ntfs (binary,noacl,posix=0,user,noumount,auto) S: on /cygdrive/s type ntfs (binary,noacl,posix=0,user,noumount,auto) V: on /cygdrive/v type ntfs (binary,noacl,posix=0,user,noumount,auto) W: on /cygdrive/w type ntfs (binary,noacl,posix=0,user,noumount,auto) -- Wes Barris -- This email has been checked for viruses by AVG. https://www.avg.com -- 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: Too many level of symbolic links (still have problem with sbmfs network drives)
Hi Takashi, On Mar 12 11:36, Takashi Yano wrote: > The problem was that GetDosDeviceW() returns unexpected string such as > "\Device\Mup\DfsClient\;Z:0003fb89\dfsserver\dfs\linkname" > for the mounted UNC path: > "\??\UNC\fileserver\share" > > This happens when UNC path for DFS is mounted to a drive with drive letter. > > Therefore, I would like to propose a workaround patch attached. > I will appreciate any comments for the patch. > - goto file_not_symlink; /* fallback */ > - remlen -= 2; > + goto file_not_symlink; /* fallback (not expected) */ Why do you add this "not expected:? It doesn't add any info, afaics, and just makes the patch bigger. > + remlen -= 2; /* Two L'\0' */ > > if (remote[remlen - 1] == L'\\') > remlen--; > @@ -3535,20 +3535,26 @@ restart: > UNICODE_STRING rpath; > RtlInitCountedUnicodeString (, remote, > remlen * sizeof (WCHAR)); > + int uncp_len = wcslen (ro_u_uncp.Buffer) - 1; You don't have to call wcslen, you already have the length in the UNICODE_STRING. I'd also constify this: const USHORT uncp_len = ro_u_uncp.Length / sizeof (WCHAR) - 1; Other than that, looks good to me. 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: Too many level of symbolic links (still have problem with sbmfs network drives)
On Fri, 11 Mar 2022 18:09:30 +0900 Takashi Yano wrote: > On Wed, 9 Mar 2022 09:58:40 +0900 > Takashi Yano wrote: > > On Tue, 8 Mar 2022 19:16:29 -0500 > > Philippe Debanne wrote: > > > Yes OK, you can send me the DLL, I will test it in the next couple of > > > days. > > > > Thanks for your cooperation. I have just sent you cygwin1.dll > > for the test. Please test it and let me know the resulted > > debug messages. > > I received the debug messages and understood what is happening. > I added a workaround for this issue, so could you please test > the cygwin1.dll with the workaround patch, and let me know the > test result? > > I will send you the patched cygwin1.dll shortly. The problem was that GetDosDeviceW() returns unexpected string such as "\Device\Mup\DfsClient\;Z:0003fb89\dfsserver\dfs\linkname" for the mounted UNC path: "\??\UNC\fileserver\share" . This happens when UNC path for DFS is mounted to a drive with drive letter. Therefore, I would like to propose a workaround patch attached. I will appreciate any comments for the patch. -- Takashi Yano 0001-Cygwin-path-Add-fallback-for-DFS-mounted-drive.patch Description: Binary data -- 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: Too many level of symbolic links (still have problem with sbmfs network drives)
On Wed, 9 Mar 2022 09:58:40 +0900 Takashi Yano wrote: > On Tue, 8 Mar 2022 19:16:29 -0500 > Philippe Debanne wrote: > > Yes OK, you can send me the DLL, I will test it in the next couple of days. > > Thanks for your cooperation. I have just sent you cygwin1.dll > for the test. Please test it and let me know the resulted > debug messages. I received the debug messages and understood what is happening. I added a workaround for this issue, so could you please test the cygwin1.dll with the workaround patch, and let me know the test result? I will send you the patched cygwin1.dll shortly. -- Takashi Yano -- 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: Too many level of symbolic links (still have problem with sbmfs network drives)
On Tue, 8 Mar 2022 19:16:29 -0500 Philippe Debanne wrote: > Yes OK, you can send me the DLL, I will test it in the next couple of days. Thanks for your cooperation. I have just sent you cygwin1.dll for the test. Please test it and let me know the resulted debug messages. -- Takashi Yano -- 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: Too many level of symbolic links (still have problem with sbmfs network drives)
Yes OK, you can send me the DLL, I will test it in the next couple of days. Le 2022-03-08 à 18:52, Takashi Yano a écrit : On Mon, 7 Mar 2022 10:32:51 -0500 Philippe Debanne wrote: sorry for the delay. I don't manage the server in question, so I can't call 'smbstatus' directly on it, but if it's any indication of version there is a path : /usr/share/doc/samba-4.10.16/ Also, attached is the /etc/smb.conf file, somewhat redacted. I installed CentOS 7 with samba 4.10.16, and add following section to /etc/samba/smb.conf which is similar section to one in smb.conf you had provided. [share$] comment = Test share path = /home/share valud users = @yano force group = yano read only = No create mask 0660 directory mask = 0770 However, the issue could not be reproduced. If I provide you with a test cygwin1.dll that outputs debug messages, can you try it out? -- 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: Too many level of symbolic links (still have problem with sbmfs network drives)
On Mon, 7 Mar 2022 10:32:51 -0500 Philippe Debanne wrote: > sorry for the delay. I don't manage the server in question, so I can't > call 'smbstatus' directly on it, but if it's any indication of version > there is a path : > > /usr/share/doc/samba-4.10.16/ > > Also, attached is the /etc/smb.conf file, somewhat redacted. I installed CentOS 7 with samba 4.10.16, and add following section to /etc/samba/smb.conf which is similar section to one in smb.conf you had provided. [share$] comment = Test share path = /home/share valud users = @yano force group = yano read only = No create mask 0660 directory mask = 0770 However, the issue could not be reproduced. If I provide you with a test cygwin1.dll that outputs debug messages, can you try it out? -- Takashi Yano -- 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: Too many level of symbolic links (still have problem with sbmfs network drives)
Hello Takashi, sorry for the delay. I don't manage the server in question, so I can't call 'smbstatus' directly on it, but if it's any indication of version there is a path : /usr/share/doc/samba-4.10.16/ Also, attached is the /etc/smb.conf file, somewhat redacted. Thanks for looking at this. Philippe Le 2022-03-07 à 10:14, Takashi Yano a écrit : On Sat, 5 Mar 2022 11:23:26 +0900 Takashi Yano wrote: On Fri, 4 Mar 2022 15:43:55 -0500 Philippe Debanne wrote: Hello Cygwin list, Since updating my Cygwin installation to the latest version, I am having the problem of "Too many levels of symbolic links" on certain network drives, that was reported in other threads. I tried replacing the 'cygwin1.dll' with the snapshots from 2022-02-17 and 2022-03-01 (x86_64). This did fix the link to one of the network drives, but not others. The mount command in my case gives : $ mount D:/cygwin64/bin on /usr/bin type ntfs (binary,auto) D:/cygwin64/lib on /usr/lib type ntfs (binary,auto) D:/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) L: on /cygdrive/l type cifs (binary,posix=0,user,noumount,auto) V: on /cygdrive/v type smbfs (binary,posix=0,user,noumount,auto) W: on /cygdrive/w type smbfs (binary,posix=0,user,noumount,auto) X: on /cygdrive/x type smbfs (binary,posix=0,user,noumount,auto) Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto) No problem with the local drives, and I can now go to the X: drive thanks to the recent snapshot. But not other 'smbfs' ones : $ cd Z: -bash: cd: Z:: Too many levels of symbolic links Any ideas what could be wrong ? It seems to be limited to certain SAMBA shared drives. Hmm, could you please provide the version of samba and hopefully smb.conf file if possible? I cannot reproduce your problem, so more information is required. [global] workgroup = DEPT realm = DEPT.INSTITUTION.CA netbios name = groupefs security = ADS idmap config *:backend = tdb idmap config *:range = 200-999 idmap config DEPT:backend = ad idmap config DEPT:schema_mode = rfc2307 idmap config DEPT:range = 1000-99 idmap config DEPT : read only = yes winbind nss info = rfc2307 client signing = yes client use spnego = yes kerberos method = secrets and keytab log file = /var/log/samba/%m.log log level = 1 auth:5 winbind:5 host msdfs = Yes hosts allow = 127.0.0.1 (...) hosts deny = 0.0.0.0/0 smb ports = 445 139 acl allow execute always = True [homes] comment = homes read only = No directory mask = 0700 force directory mode = 0700 create mask = 0600 force create mode = 0600 browseable = No valid users = %S follow symlinks = yes [recherche$] comment = Section Groupe Recherche path = /store2/share/recherche valid users = @recherche #force user = root force group = recherche read only = No create mask = 0660 directory mask = 0770 [recherche2$] comment = Section Groupe Recherche2 path = /store2/share/recherche2 valid users = @recherche,user1,user2,user3 #force user = root force group = recherche read only = No create mask = 0660 directory mask = 0770 -- 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: Too many level of symbolic links (still have problem with sbmfs network drives)
On Sat, 5 Mar 2022 11:23:26 +0900 Takashi Yano wrote: > On Fri, 4 Mar 2022 15:43:55 -0500 > Philippe Debanne wrote: > > Hello Cygwin list, > > > > Since updating my Cygwin installation to the latest version, I am having > > the problem of "Too many levels of symbolic links" on certain network > > drives, that was reported in other threads. I tried replacing the > > 'cygwin1.dll' with the snapshots from 2022-02-17 and 2022-03-01 > > (x86_64). This did fix the link to one of the network drives, but not > > others. > > > > The mount command in my case gives : > > > > $ mount > > D:/cygwin64/bin on /usr/bin type ntfs (binary,auto) > > D:/cygwin64/lib on /usr/lib type ntfs (binary,auto) > > D:/cygwin64 on / type ntfs (binary,auto) > > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > > D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) > > L: on /cygdrive/l type cifs (binary,posix=0,user,noumount,auto) > > V: on /cygdrive/v type smbfs (binary,posix=0,user,noumount,auto) > > W: on /cygdrive/w type smbfs (binary,posix=0,user,noumount,auto) > > X: on /cygdrive/x type smbfs (binary,posix=0,user,noumount,auto) > > Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) > > Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto) > > > > No problem with the local drives, and I can now go to the X: drive > > thanks to the recent snapshot. But not other 'smbfs' ones : > > > > $ cd Z: > > -bash: cd: Z:: Too many levels of symbolic links > > > > Any ideas what could be wrong ? It seems to be limited to certain SAMBA > > shared drives. > > Hmm, could you please provide the version of samba > and hopefully smb.conf file if possible? I cannot reproduce your problem, so more information is required. -- Takashi Yano -- 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: Too many level of symbolic links (still have problem with sbmfs network drives)
On Fri, 4 Mar 2022 15:43:55 -0500 Philippe Debanne wrote: > Hello Cygwin list, > > Since updating my Cygwin installation to the latest version, I am having > the problem of "Too many levels of symbolic links" on certain network > drives, that was reported in other threads. I tried replacing the > 'cygwin1.dll' with the snapshots from 2022-02-17 and 2022-03-01 > (x86_64). This did fix the link to one of the network drives, but not > others. > > The mount command in my case gives : > > $ mount > D:/cygwin64/bin on /usr/bin type ntfs (binary,auto) > D:/cygwin64/lib on /usr/lib type ntfs (binary,auto) > D:/cygwin64 on / type ntfs (binary,auto) > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) > L: on /cygdrive/l type cifs (binary,posix=0,user,noumount,auto) > V: on /cygdrive/v type smbfs (binary,posix=0,user,noumount,auto) > W: on /cygdrive/w type smbfs (binary,posix=0,user,noumount,auto) > X: on /cygdrive/x type smbfs (binary,posix=0,user,noumount,auto) > Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) > Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto) > > No problem with the local drives, and I can now go to the X: drive > thanks to the recent snapshot. But not other 'smbfs' ones : > > $ cd Z: > -bash: cd: Z:: Too many levels of symbolic links > > Any ideas what could be wrong ? It seems to be limited to certain SAMBA > shared drives. Hmm, could you please provide the version of samba and hopefully smb.conf file if possible? -- Takashi Yano -- 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
Too many level of symbolic links (still have problem with sbmfs network drives)
Hello Cygwin list, Since updating my Cygwin installation to the latest version, I am having the problem of "Too many levels of symbolic links" on certain network drives, that was reported in other threads. I tried replacing the 'cygwin1.dll' with the snapshots from 2022-02-17 and 2022-03-01 (x86_64). This did fix the link to one of the network drives, but not others. The mount command in my case gives : $ mount D:/cygwin64/bin on /usr/bin type ntfs (binary,auto) D:/cygwin64/lib on /usr/lib type ntfs (binary,auto) D:/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) L: on /cygdrive/l type cifs (binary,posix=0,user,noumount,auto) V: on /cygdrive/v type smbfs (binary,posix=0,user,noumount,auto) W: on /cygdrive/w type smbfs (binary,posix=0,user,noumount,auto) X: on /cygdrive/x type smbfs (binary,posix=0,user,noumount,auto) Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto) No problem with the local drives, and I can now go to the X: drive thanks to the recent snapshot. But not other 'smbfs' ones : $ cd Z: -bash: cd: Z:: Too many levels of symbolic links Any ideas what could be wrong ? It seems to be limited to certain SAMBA shared drives. - Philippe -- 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: too many level of symbolic links
> Of Corinna Vinschen > Sent: Thursday, February 17, 2022 1:00 PM > To: cygwin@cygwin.com > Subject: Re: too many level of symbolic links > > On Feb 17 11:41, Andreas Heckel wrote: > > > > > > > Of Oskar Skog > > > Sent: Thursday, February 17, 2022 11:05 AM > > > Subject: Re: too many level of symbolic links > > > > > > On 2022-02-17 10:46, Andreas Heckel wrote: > > > > I have a network drive mapped like > > > > //hostname/share --> p: > > > > > > > > When trying to access the network drive via cygwin I get: > > > > > > > > $ ls /cygdrive/p > > > > ls: cannot open directory '/cygdrive/p': Too many levels of symbolic > > > links > > > > > > > > Accessing the network share directly via //hostname/share works as > > > normal. > > > > > > > > I have been using cygwin a long time but this is the first time this > > > happens. My machine and our servers got recently updated, so I can't > > > really pinpoint the reason for this behaviour now. > > > > > > > > Any hints / advice how to resolve this? > > > > > > > > Cheers, Andreas > > > > > > > > > > > > > > > > > > > > Are you running the newest version of Cygwin (3.3.4)?, there have been > > > a similar issue to yours in the previous version that should have been > > > fixed. > > > > > > > Just to be certain, I ran setup again. There are currently no pending > updates. > > > > 3472k 2022/01/31 C:\cygwin64\bin\cygwin1.dll > > Cygwin DLL version info: > > DLL version: 3.3.4 > > There was YA patch necessary to fix this regression > https://sourceware.org/git/?p=newlib- > cygwin.git;a=commitdiff;h=71d5490a3a2d > and that patch isn't in 3.3.4. Please test the latest (2022-02-17) > Cygwin snapshot DLL from https://cygwin.com/snapshots/ Confirmed, snapshot version of cygwin1.dll solves the issue. :) Thanks, Andreas -- 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: too many level of symbolic links
On Feb 17 11:41, Andreas Heckel wrote: > > > > Of Oskar Skog > > Sent: Thursday, February 17, 2022 11:05 AM > > Subject: Re: too many level of symbolic links > > > > On 2022-02-17 10:46, Andreas Heckel wrote: > > > I have a network drive mapped like > > > //hostname/share --> p: > > > > > > When trying to access the network drive via cygwin I get: > > > > > > $ ls /cygdrive/p > > > ls: cannot open directory '/cygdrive/p': Too many levels of symbolic > > links > > > > > > Accessing the network share directly via //hostname/share works as > > normal. > > > > > > I have been using cygwin a long time but this is the first time this > > happens. My machine and our servers got recently updated, so I can't > > really pinpoint the reason for this behaviour now. > > > > > > Any hints / advice how to resolve this? > > > > > > Cheers, Andreas > > > > > > > > > > > > > > Are you running the newest version of Cygwin (3.3.4)?, there have been > > a similar issue to yours in the previous version that should have been > > fixed. > > > > Just to be certain, I ran setup again. There are currently no pending updates. > > 3472k 2022/01/31 C:\cygwin64\bin\cygwin1.dll > Cygwin DLL version info: > DLL version: 3.3.4 There was YA patch necessary to fix this regression https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=71d5490a3a2d and that patch isn't in 3.3.4. Please test the latest (2022-02-17) Cygwin snapshot DLL from https://cygwin.com/snapshots/ 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: too many level of symbolic links
> Of Oskar Skog > Sent: Thursday, February 17, 2022 11:05 AM > Subject: Re: too many level of symbolic links > > On 2022-02-17 10:46, Andreas Heckel wrote: > > I have a network drive mapped like > > //hostname/share --> p: > > > > When trying to access the network drive via cygwin I get: > > > > $ ls /cygdrive/p > > ls: cannot open directory '/cygdrive/p': Too many levels of symbolic > links > > > > Accessing the network share directly via //hostname/share works as > normal. > > > > I have been using cygwin a long time but this is the first time this > happens. My machine and our servers got recently updated, so I can't > really pinpoint the reason for this behaviour now. > > > > Any hints / advice how to resolve this? > > > > Cheers, Andreas > > > > > > > > Are you running the newest version of Cygwin (3.3.4)?, there have been > a similar issue to yours in the previous version that should have been > fixed. > Just to be certain, I ran setup again. There are currently no pending updates. 3472k 2022/01/31 C:\cygwin64\bin\cygwin1.dll Cygwin DLL version info: DLL version: 3.3.4 -- 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: too many level of symbolic links
On 2022-02-17 10:46, Andreas Heckel wrote: I have a network drive mapped like //hostname/share --> p: When trying to access the network drive via cygwin I get: $ ls /cygdrive/p ls: cannot open directory '/cygdrive/p': Too many levels of symbolic links Accessing the network share directly via //hostname/share works as normal. I have been using cygwin a long time but this is the first time this happens. My machine and our servers got recently updated, so I can't really pinpoint the reason for this behaviour now. Any hints / advice how to resolve this? Cheers, Andreas Are you running the newest version of Cygwin (3.3.4)?, there have been a similar issue to yours in the previous version that should have been fixed. -- 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
too many level of symbolic links
I have a network drive mapped like //hostname/share --> p: When trying to access the network drive via cygwin I get: $ ls /cygdrive/p ls: cannot open directory '/cygdrive/p': Too many levels of symbolic links Accessing the network share directly via //hostname/share works as normal. I have been using cygwin a long time but this is the first time this happens. My machine and our servers got recently updated, so I can't really pinpoint the reason for this behaviour now. Any hints / advice how to resolve this? Cheers, Andreas -- 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: Follow-up to: vboxsharedfs - Too many levels of symbolic links
back on mailing list, please reply always there On 02.01.2022 08:09, cyg...@kosowsky.org wrote: Thanks. It works! Nice to know Marco Atzeri wrote at about 00:33:29 +0100 on Sunday, January 2, 2022: > On 02.01.2022 00:01, cyg...@kosowsky.org wrote: > > Hi, > > About a month ago, a thread with the above title mentioned that a > > patch to the problem was submitted. > > > > I am encountering the same problem on my Cygwin/Win10/Vbox 6.1.30 > > installation. > > > > Any idea when that patch will be pushed to production? > > Or barring that, is there a test version that I could download > > somewhere as this bug is somewhat limiting for me at this point... > > > > Snapshots are here: > https://cygwin.com/snapshots/ > Regards Marco -- 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: Follow-up to: vboxsharedfs - Too many levels of symbolic links
On 02.01.2022 00:01, cyg...@kosowsky.org wrote: Hi, About a month ago, a thread with the above title mentioned that a patch to the problem was submitted. I am encountering the same problem on my Cygwin/Win10/Vbox 6.1.30 installation. Any idea when that patch will be pushed to production? Or barring that, is there a test version that I could download somewhere as this bug is somewhat limiting for me at this point... Snapshots are here: https://cygwin.com/snapshots/ -- 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
Follow-up to: vboxsharedfs - Too many levels of symbolic links
Hi, About a month ago, a thread with the above title mentioned that a patch to the problem was submitted. I am encountering the same problem on my Cygwin/Win10/Vbox 6.1.30 installation. Any idea when that patch will be pushed to production? Or barring that, is there a test version that I could download somewhere as this bug is somewhat limiting for me at this point... -- 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: vboxsharedfs - Too many levels of symbolic links
On Dec 9 17:16, Takashi Yano wrote: > On Wed, 8 Dec 2021 11:37:39 +0100 > Corinna Vinschen wrote: > > On Dec 8 17:20, Takashi Yano wrote: > > > On Tue, 7 Dec 2021 18:15:42 +0100 > > > I confirmed that your patch works nicely. > > > > > > ...except when the drive is created by subst using UNC path, > > > e.g. subst w: \\server\share. > > > > > > In this case, WNetGetConnectionW() fails with ERROR_NO_NET_OR_BAD_PATH. > > > > > > So, I modified your patch a bit. > > > > > > What about attached patch? > > > > Oh, great! GetVolumePathNameW is the function I somehow missed when > > looking into the Microsoft docs yesterday, so thanks for modifying the > > patch this way. > > > > Please push. > > I noticed that this code does not work if UNC path "\\server\share\dir" > (rather than "\\server\share") is mounted to virtual drive. Oh drat, I tried that explicitely and I saw that WNetGetConnectionW returns the same as `net use' on the command line. So GetVolumePathNameW only returns the actual share name? Sigh. > I will submit a patch for this issue. Sorry for testing insufficiently. No worries and 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: vboxsharedfs - Too many levels of symbolic links
On Wed, 8 Dec 2021 11:37:39 +0100 Corinna Vinschen wrote: > On Dec 8 17:20, Takashi Yano wrote: > > On Tue, 7 Dec 2021 18:15:42 +0100 > > I confirmed that your patch works nicely. > > > > ...except when the drive is created by subst using UNC path, > > e.g. subst w: \\server\share. > > > > In this case, WNetGetConnectionW() fails with ERROR_NO_NET_OR_BAD_PATH. > > > > So, I modified your patch a bit. > > > > What about attached patch? > > Oh, great! GetVolumePathNameW is the function I somehow missed when > looking into the Microsoft docs yesterday, so thanks for modifying the > patch this way. > > Please push. I noticed that this code does not work if UNC path "\\server\share\dir" (rather than "\\server\share") is mounted to virtual drive. I will submit a patch for this issue. Sorry for testing insufficiently. -- Takashi Yano -- 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: vboxsharedfs - Too many levels of symbolic links
On Dec 8 17:20, Takashi Yano wrote:
> On Tue, 7 Dec 2021 18:15:42 +0100
> Corinna Vinschen wrote:
> > Hi Takashi,
> >
> > - Forwarded message from Corinna Vinschen
> > -
> > > The idea of the GFPNBH call is to short-circuit the path_conv handling
> > > in case we have native Windows symlinks in the path. My example above
> > > was only considering what comes out of the `if ((pc_flags & ...) { ... }
> > > ' expression starting in line 3485 (assuming "b" is a native symlink).
> > >
> > > What I mean is this: Your patch disregards the entire string returned by
> > > GFPNBH, if the returned path is an UNC path, no matter what.
> > >
> > > But what if the incoming path already *was* an UNC path, and potentially
> > > contains native symlinks? In that case you have no reason to disregard
> > > the resulting path from GFPNBH.
> > >
> > > And if it was a drive letter path, wouldn't it be nicer to just convert
> > > the UNC path prefix back to the drive letter and keep the rest of the
> > > final path intact?
> > >
> > > However, both of these scenarios require extra code, which isn't that
> > > important for now, so, never mind.
> > - End forwarded message -
> >
> > What I meant is something like the below (entirely untested). Yeah, I'm
> > not sure myself, if it's worth the effort...
> > [...]
> I confirmed that your patch works nicely.
>
> ...except when the drive is created by subst using UNC path,
> e.g. subst w: \\server\share.
>
> In this case, WNetGetConnectionW() fails with ERROR_NO_NET_OR_BAD_PATH.
>
> So, I modified your patch a bit.
>
> What about attached patch?
Oh, great! GetVolumePathNameW is the function I somehow missed when
looking into the Microsoft docs yesterday, so thanks for modifying the
patch this way.
Please push.
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: vboxsharedfs - Too many levels of symbolic links
On Tue, 7 Dec 2021 18:15:42 +0100
Corinna Vinschen wrote:
> Hi Takashi,
>
> - Forwarded message from Corinna Vinschen
> -
> > The idea of the GFPNBH call is to short-circuit the path_conv handling
> > in case we have native Windows symlinks in the path. My example above
> > was only considering what comes out of the `if ((pc_flags & ...) { ... }
> > ' expression starting in line 3485 (assuming "b" is a native symlink).
> >
> > What I mean is this: Your patch disregards the entire string returned by
> > GFPNBH, if the returned path is an UNC path, no matter what.
> >
> > But what if the incoming path already *was* an UNC path, and potentially
> > contains native symlinks? In that case you have no reason to disregard
> > the resulting path from GFPNBH.
> >
> > And if it was a drive letter path, wouldn't it be nicer to just convert
> > the UNC path prefix back to the drive letter and keep the rest of the
> > final path intact?
> >
> > However, both of these scenarios require extra code, which isn't that
> > important for now, so, never mind.
> - End forwarded message -
>
> What I meant is something like the below (entirely untested). Yeah, I'm
> not sure myself, if it's worth the effort...
>
> diff --git a/winsup/cygwin/autoload.cc b/winsup/cygwin/autoload.cc
> index e254397257fd..06afd2d62996 100644
> --- a/winsup/cygwin/autoload.cc
> +++ b/winsup/cygwin/autoload.cc
> @@ -630,6 +630,7 @@ LoadDLLfunc (LdapMapErrorToWin32, 0, wldap32)
>
> LoadDLLfunc (WNetCloseEnum, 4, mpr)
> LoadDLLfunc (WNetEnumResourceW, 16, mpr)
> +LoadDLLfunc (WNetGetConnectionW, 12, mpr)
> LoadDLLfunc (WNetGetProviderNameW, 12, mpr)
> LoadDLLfunc (WNetGetResourceInformationW, 16, mpr)
> LoadDLLfunc (WNetOpenEnumW, 20, mpr)
> diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
> index baf04ce89a08..c7b29acf29b3 100644
> --- a/winsup/cygwin/path.cc
> +++ b/winsup/cygwin/path.cc
> @@ -3492,10 +3492,41 @@ restart:
> {
> UNICODE_STRING fpath;
>
> - RtlInitCountedUnicodeString (, fpbuf, ret * sizeof (WCHAR));
> + /* If incoming path has no trailing backslash, but final path
> + has one, drop trailing backslash from final path so the
> + below string comparison has a chance to succeed. */
> + if (upath.Buffer[(upath.Length - 1) / sizeof (WCHAR)] != L'\\'
> + && fpbuf[ret - 1] == L'\\')
> +fpbuf[--ret] = L'\0';
> fpbuf[1] = L'?'; /* \\?\ --> \??\ */
> + RtlInitCountedUnicodeString (, fpbuf, ret * sizeof (WCHAR));
> if (!RtlEqualUnicodeString (, , !!ci_flag))
> {
> + /* Check if the final path is an UNC path and the incoming
> + path isn't. If so... */
> + if (RtlEqualUnicodePathPrefix (, _u_uncp, TRUE)
> + && !RtlEqualUnicodePathPrefix (, _u_uncp, TRUE))
> + {
> + /* ...extract the drive letter, get the remote path,
> + replace remote path with drive letter, check again. */
> + WCHAR drive[3] = { upath.Buffer[4], L':', L'\0' };
> + WCHAR remote[MAX_PATH];
> +
> + if (WNetGetConnectionW (drive, remote, MAX_PATH)
> + == NO_ERROR)
> + {
> + /* Hackfest */
> + fpath.Buffer[4] = drive[0];
> + fpath.Buffer[5] = L':';
> + WCHAR to = fpath.Buffer + 6;
> + WCHAR from = to + wcslen (remote);
> + memmove (to, from,
> +(wcslen (from) + 1) * sizeof (WCHAR));
> + fpath.Length -= (from - to) * sizeof (WCHAR);
> + if (RtlEqualUnicodeString (, , !!ci_flag))
> + goto file_not_symlink;
> + }
> + }
> issymlink = true;
> /* upath.Buffer is big enough and unused from this point on.
>Reuse it here, avoiding yet another buffer allocation. */
I confirmed that your patch works nicely.
...except when the drive is created by subst using UNC path,
e.g. subst w: \\server\share.
In this case, WNetGetConnectionW() fails with ERROR_NO_NET_OR_BAD_PATH.
So, I modified your patch a bit.
What about attached patch?
--
Takashi Yano
0001-Cygwin-path-Convert-UNC-path-prefix-back-to-drive-le.patch
Description: Binary data
--
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: vboxsharedfs - Too many levels of symbolic links
On Dec 8 00:32, Takashi Yano wrote:
> On Tue, 7 Dec 2021 15:57:56 +0100
> Corinna Vinschen wrote:
> > On Dec 7 09:46, Takashi Yano wrote:
> > > I think '/cygdrive/z/..' should be '/cygdrive', however,
> > > in current cygwin, it is interpreted into '//VBoxSrv'.
> > >
> > > Is this as you intended?
> > >
> > > With my patch which stops to treat UNC path as symlink,
> > > '/cygdrive/z/..' returns '/cygdrive'.
> >
> > Yeah, but...
> >
> > ...what bugs me is that *every* UNC path is treated this way with
> > that patch. If you have a path like /cygdrive/x/a/b/c, with x:
> > being a virtual drive pointing to //server/share, and with "b"
> > being a symlink to "syml", what you get back is either
> >
> > //server/share/a/syml/c
> >
> > without, or
> >
> > /cygdrive/x/a/b/c
> >
> > with your patch. What we would like to get back is
> >
> > /cygdrive/x/a/syml/c
>
> With my patch, above case behaves like:
>
> $ mount
> C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
> Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto)
> $ cd /cygdrive/z
> $ mkdir -p aa/syml/cc
> $ ln -s syml aa/bb
> $ cd aa/bb/cc
> $ /bin/pwd
> /cygdrive/z/aa/syml/cc
> $
>
> Isn't this what you would like?
Sorry, I wasn't expressing myself clearly. The end result is what is
expected, yes. But that's the result of the full path_conv conversion,
which wasn't what I was up to.
The idea of the GFPNBH call is to short-circuit the path_conv handling
in case we have native Windows symlinks in the path. My example above
was only considering what comes out of the `if ((pc_flags & ...) { ... }
' expression starting in line 3485 (assuming "b" is a native symlink).
What I mean is this: Your patch disregards the entire string returned by
GFPNBH, if the returned path is an UNC path, no matter what.
But what if the incoming path already *was* an UNC path, and potentially
contains native symlinks? In that case you have no reason to disregard
the resulting path from GFPNBH.
And if it was a drive letter path, wouldn't it be nicer to just convert
the UNC path prefix back to the drive letter and keep the rest of the
final path intact?
However, both of these scenarios require extra code, which isn't that
important for now, so, never mind.
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: vboxsharedfs - Too many levels of symbolic links
On Wed, 8 Dec 2021 00:32:49 +0900 Takashi Yano wrote: > With my patch, above case behaves like: > > $ mount > C:/cygwin/bin on /usr/bin type ntfs (binary,auto) > C:/cygwin/lib on /usr/lib type ntfs (binary,auto) > C:/cygwin on / type ntfs (binary,auto) > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto) > Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto) > $ cd /cygdrive/z > $ mkdir -p aa/syml/cc > $ ln -s syml aa/bb > $ cd aa/bb/cc > $ /bin/pwd > /cygdrive/z/aa/syml/cc > $ $ cygpath -a . /cygdrive/z/aa/syml/cc/ $ echo -e 'all:\n\t@echo CURDIR=$(CURDIR)' > Makefile $ make -C . make: Entering directory '/cygdrive/z/aa/syml/cc' CURDIR=/cygdrive/z/aa/syml/cc make: Leaving directory '/cygdrive/z/aa/syml/cc' > Isn't this what you would like? -- Takashi Yano -- 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: vboxsharedfs - Too many levels of symbolic links
On Tue, 7 Dec 2021 15:57:56 +0100 Corinna Vinschen wrote: > On Dec 7 09:46, Takashi Yano wrote: > > I think '/cygdrive/z/..' should be '/cygdrive', however, > > in current cygwin, it is interpreted into '//VBoxSrv'. > > > > Is this as you intended? > > > > With my patch which stops to treat UNC path as symlink, > > '/cygdrive/z/..' returns '/cygdrive'. > > Yeah, but... > > ...what bugs me is that *every* UNC path is treated this way with > that patch. If you have a path like /cygdrive/x/a/b/c, with x: > being a virtual drive pointing to //server/share, and with "b" > being a symlink to "syml", what you get back is either > > //server/share/a/syml/c > > without, or > > /cygdrive/x/a/b/c > > with your patch. What we would like to get back is > > /cygdrive/x/a/syml/c With my patch, above case behaves like: $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto) Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto) $ cd /cygdrive/z $ mkdir -p aa/syml/cc $ ln -s syml aa/bb $ cd aa/bb/cc $ /bin/pwd /cygdrive/z/aa/syml/cc $ Isn't this what you would like? > So the real problem is not that we have an UNC path, but the fact that > the drive letter expression is (correctly, but unwanted) converted to > the matching UNC path by GetFinalPathNameByHandle. > > Bottom line is, your patch is ok, please apply. It would be nice, > though, if we could just avoid the drive: -> UNC path conversion and > keep the rest. -- Takashi Yano -- 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: vboxsharedfs - Too many levels of symbolic links
On Dec 7 09:46, Takashi Yano wrote: > On Mon, 6 Dec 2021 19:55:27 +0900 > Takashi Yano wrote: > > First, I think the same. However, with this patch, it sometimes causes > > hang for a few seconds around the code: > [...] > > with path_copy of "//VBoxSrv". I am not sure why. That's expected and nothing really to worry about. It's the network environment access in fhandler_netdrive. I have this on the radar already, because the WNet stuff in there has been broken by Microsoft with certain updates to Windows 10. A SMB security fix has deliberately left behind the WNet calls to enumerate the network environment, because they rely on functionality of older SMB versions. > > > > In addition, > > https://cygwin.com/pipermail/cygwin/2021-December/250103.html > > still needs fix. > > Moreover, this has a problem with "ls -al /cygdrive/z". > The information for ".." is not retrieved correctly. > > drwxr-xr-x 1 yano None 0 Dec 6 13:54 . > d? ? ?? ?? .. > -rw-r--r-- 1 yano None 29 Dec 4 07:45 Makefile > -rw-r--r-- 1 yano None 17 Dec 6 13:18 a > drwxr-xr-x 1 yano None 0 Dec 6 08:59 aaa > lrwxrwxrwx 1 yano None 1 Dec 6 13:54 b -> a > -rwxr-xr-x 1 yano None 3278626 Dec 7 09:07 cygwin0.dll > -rwxr-xr-x 1 yano None 3549860 Dec 6 08:51 cygwin0.dll.64 > -rw-r--r-- 1 yano None 0 Dec 3 22:16 testfile.txt > > I think '/cygdrive/z/..' should be '/cygdrive', however, > in current cygwin, it is interpreted into '//VBoxSrv'. > > Is this as you intended? > > With my patch which stops to treat UNC path as symlink, > '/cygdrive/z/..' returns '/cygdrive'. Yeah, but... ...what bugs me is that *every* UNC path is treated this way with that patch. If you have a path like /cygdrive/x/a/b/c, with x: being a virtual drive pointing to //server/share, and with "b" being a symlink to "syml", what you get back is either //server/share/a/syml/c without, or /cygdrive/x/a/b/c with your patch. What we would like to get back is /cygdrive/x/a/syml/c So the real problem is not that we have an UNC path, but the fact that the drive letter expression is (correctly, but unwanted) converted to the matching UNC path by GetFinalPathNameByHandle. Bottom line is, your patch is ok, please apply. It would be nice, though, if we could just avoid the drive: -> UNC path conversion and keep the rest. 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: vboxsharedfs - Too many levels of symbolic links
On Mon, 6 Dec 2021 19:55:27 +0900 Takashi Yano wrote: > First, I think the same. However, with this patch, it sometimes causes > hang for a few seconds around the code: [...] > with path_copy of "//VBoxSrv". I am not sure why. > > In addition, > https://cygwin.com/pipermail/cygwin/2021-December/250103.html > still needs fix. Moreover, this has a problem with "ls -al /cygdrive/z". The information for ".." is not retrieved correctly. drwxr-xr-x 1 yano None 0 Dec 6 13:54 . d? ? ?? ?? .. -rw-r--r-- 1 yano None 29 Dec 4 07:45 Makefile -rw-r--r-- 1 yano None 17 Dec 6 13:18 a drwxr-xr-x 1 yano None 0 Dec 6 08:59 aaa lrwxrwxrwx 1 yano None 1 Dec 6 13:54 b -> a -rwxr-xr-x 1 yano None 3278626 Dec 7 09:07 cygwin0.dll -rwxr-xr-x 1 yano None 3549860 Dec 6 08:51 cygwin0.dll.64 -rw-r--r-- 1 yano None 0 Dec 3 22:16 testfile.txt I think '/cygdrive/z/..' should be '/cygdrive', however, in current cygwin, it is interpreted into '//VBoxSrv'. Is this as you intended? With my patch which stops to treat UNC path as symlink, '/cygdrive/z/..' returns '/cygdrive'. -- Takashi Yano -- 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: vboxsharedfs - Too many levels of symbolic links
On Mon, 6 Dec 2021 11:16:30 +0100
Corinna Vinschen wrote:
> > For example, RtlEqualUnicodeString() compares \??\UNC\VBoxSrv\tmp and
> > \??\UNC\VBoxSrv\tmp\, then it fails.
> > [...]
> > + if (wcsstr (fpbuf, L"?\\UNC\\") == fpbuf)
> > + goto file_not_symlink;
> > +
>
> Isn't that a bit intrusive? Wouldn't it also fix the issue if we
> just overwrite a trailing '\\' with '\0', like this?
>
> diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
> index baf04ce89a08..b76e5b0466cf 100644
> --- a/winsup/cygwin/path.cc
> +++ b/winsup/cygwin/path.cc
> @@ -3492,8 +3492,14 @@ restart:
> {
> UNICODE_STRING fpath;
>
> - RtlInitCountedUnicodeString (, fpbuf, ret * sizeof (WCHAR));
> + /* If incoming path has no trailing backslash, but final path
> + has one, drop trailing backslash from final path so the
> + below string comparison has a chance to succeed. */
> + if (upath.Buffer[(upath.Length - 1) / sizeof (WCHAR)] != L'\\'
> + && fpbuf[ret - 1] == L'\\')
> + fpbuf[--ret] = L'\0';
> fpbuf[1] = L'?'; /* \\?\ --> \??\ */
> + RtlInitCountedUnicodeString (, fpbuf, ret * sizeof (WCHAR));
> if (!RtlEqualUnicodeString (, , !!ci_flag))
> {
> issymlink = true;
First, I think the same. However, with this patch, it sometimes causes
hang for a few seconds around the code:
else if (isvirtual_dev (dev))
{
/* FIXME: Calling build_fhandler here is not the right way to
handle this. */
fhandler_virtual *fh = (fhandler_virtual *)
build_fh_dev (dev, path_copy);
virtual_ftype_t file_type;
if (!fh)
file_type = virt_none;
else
{
file_type = fh->exists ();
if (file_type == virt_symlink
|| file_type == virt_fdsymlink)
{
fh->fill_filebuf ();
symlen = sym.set (fh->get_filebuf ());
}
with path_copy of "//VBoxSrv". I am not sure why.
In addition,
https://cygwin.com/pipermail/cygwin/2021-December/250103.html
still needs fix.
So I proposed the patch which stops to treat UNC path as symlink.
--
Takashi Yano
--
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: vboxsharedfs - Too many levels of symbolic links
On Dec 5 11:54, Takashi Yano wrote:
> On Tue, 30 Nov 2021 19:04:57 +0200
> Oskar Skog wrote:
> > vboxsharedfs file systems no longer work. Any attempt to access will
> > result in "too many levels of symbolic links".
> >
> > This only affects the VirtualBox shared folder, the Samba share works
> > just fine.
> >
> > Last time I updated (before today) was sometime before the 10th of
> > September.
> >
> > MSYS2 has the same problem, but no one seems to have reported it to
> > Cygwin:
> > https://github.com/msys2/msys2-runtime/issues/58
> >
> >
> > user@DESKTOP-*** ~$ ls /cygdrive/z
> > ls: cannot access '/cygdrive/z': Too many levels of symbolic links
> > user@DESKTOP-*** ~$ mount
> > C:/Cygwin/bin on /usr/bin type ntfs (binary,auto)
> > C:/Cygwin/lib on /usr/lib type ntfs (binary,auto)
> > C:/Cygwin on / type ntfs (binary,auto)
> > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> > D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
> > Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto)
> > Z: on /cygdrive/z type vboxsharedfolderfs
> > (binary,posix=0,user,noumount,auto)
> > user@DESKTOP-*** ~$ uname -a
> > CYGWIN_NT-10.0 DESKTOP-* 3.3.2(0.341/5/3) 2021-11-08 16:55 x86_64 Cygwin
>
> Thanks for the report.
> It seems that this happens only in 64bit Windoes10/11.
> [...]
> I tested with VirtualBox version 6.1.30.
Thanks for testing, Takashi!
> In 64bit Windows10, for vbox shared path, GetFinalPathNameByHandleW()
> returns path with trailing '\'. As a result, RtlEqualUnicodeString()
> fails and tries to resolve symlink repeatedly.
That sounds like a bug in VirtualBox, but yeah, we should workaround it.
> For example, RtlEqualUnicodeString() compares \??\UNC\VBoxSrv\tmp and
> \??\UNC\VBoxSrv\tmp\, then it fails.
> [...]
> + if (wcsstr (fpbuf, L"?\\UNC\\") == fpbuf)
> + goto file_not_symlink;
> +
Isn't that a bit intrusive? Wouldn't it also fix the issue if we
just overwrite a trailing '\\' with '\0', like this?
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index baf04ce89a08..b76e5b0466cf 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -3492,8 +3492,14 @@ restart:
{
UNICODE_STRING fpath;
- RtlInitCountedUnicodeString (, fpbuf, ret * sizeof (WCHAR));
+ /* If incoming path has no trailing backslash, but final path
+has one, drop trailing backslash from final path so the
+below string comparison has a chance to succeed. */
+ if (upath.Buffer[(upath.Length - 1) / sizeof (WCHAR)] != L'\\'
+ && fpbuf[ret - 1] == L'\\')
+ fpbuf[--ret] = L'\0';
fpbuf[1] = L'?'; /* \\?\ --> \??\ */
+ RtlInitCountedUnicodeString (, fpbuf, ret * sizeof (WCHAR));
if (!RtlEqualUnicodeString (, , !!ci_flag))
{
issymlink = true;
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: vboxsharedfs - Too many levels of symbolic links
On Mon, 6 Dec 2021 12:31:35 +0900 Takashi Yano wrote: > cygwin symbolic link seems to work only in NTFS file system. This is not right. cygwin symlink needs 'SYSTEM' attribute. So it does not work in file system which does not support that attributes. Windows file system, such as NTFS, FAT, supports it. > If shared folder is in linux file system, cygwin symbolic link > does not work. Basically, linux file system does not support 'SYSTEM' attribute, but samba support it using extended attributes if 'store dos attributes' is set to 'yes' (by default since samba 4.9). -- Takashi Yano -- 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: vboxsharedfs - Too many levels of symbolic links
On 2021-12-06 05:31, Takashi Yano wrote: On Sun, 5 Dec 2021 16:49:13 +0200 Oskar Skog wrote: But if I create a symlink on that filesystem, it's not identified as a symlink. Although, I don't know if this has ever worked as it is the first time I've ever tested it, it probably hasn't ever worked (see below). user@DESKTOP-*** /cygdrive/z$ ln -s report.pdf test.pdf user@DESKTOP-*** /cygdrive/z$ ls -l report.pdf test.pdf -rw-r--r-- 1 user None 1454562 Nov 28 12:05 report.pdf -rw-r--r-- 1 user None 34 Dec 5 16:36 test.pdf user@DESKTOP-*** /cygdrive/z$ cat test.pdf !▒▒report.pdfuser@DESKTOP-*** /cygdrive/z$ I think it's because "special" attributes don't work on VirtualBox shared folders, I can't hide files in Explorer either. So I don't think the patch has caused any regression here. I cannot reproduce that behaviour. yano@DESKTOP-LSNFFD0 /cygdrive/z $ echo > a yano@DESKTOP-LSNFFD0 /cygdrive/z $ ln -s a b yano@DESKTOP-LSNFFD0 /cygdrive/z $ ls -l b lrwxrwxrwx 1 yano None 1 Dec 6 12:17 b -> a yano@DESKTOP-LSNFFD0 /cygdrive/z $ cat b yano@DESKTOP-LSNFFD0 /cygdrive/z $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto) Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto) Are you running VirtualBox in non-windows host by any chance? cygwin symbolic link seems to work only in NTFS file system. If shared folder is in linux file system, cygwin symbolic link does not work. Yes, I'm on a Linux host. -- 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: vboxsharedfs - Too many levels of symbolic links
On Sun, 5 Dec 2021 16:49:13 +0200 Oskar Skog wrote: > But if I create a symlink on that filesystem, it's not identified as a > symlink. Although, I don't know if this has ever worked as it is the > first time I've ever tested it, it probably hasn't ever worked (see > below). > > user@DESKTOP-*** /cygdrive/z$ ln -s report.pdf test.pdf > user@DESKTOP-*** /cygdrive/z$ ls -l report.pdf test.pdf > -rw-r--r-- 1 user None 1454562 Nov 28 12:05 report.pdf > -rw-r--r-- 1 user None 34 Dec 5 16:36 test.pdf > user@DESKTOP-*** /cygdrive/z$ cat test.pdf > !▒▒report.pdfuser@DESKTOP-*** /cygdrive/z$ > > I think it's because "special" attributes don't work on VirtualBox > shared folders, I can't hide files in Explorer either. > > So I don't think the patch has caused any regression here. I cannot reproduce that behaviour. yano@DESKTOP-LSNFFD0 /cygdrive/z $ echo > a yano@DESKTOP-LSNFFD0 /cygdrive/z $ ln -s a b yano@DESKTOP-LSNFFD0 /cygdrive/z $ ls -l b lrwxrwxrwx 1 yano None 1 Dec 6 12:17 b -> a yano@DESKTOP-LSNFFD0 /cygdrive/z $ cat b yano@DESKTOP-LSNFFD0 /cygdrive/z $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto) Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto) Are you running VirtualBox in non-windows host by any chance? cygwin symbolic link seems to work only in NTFS file system. If shared folder is in linux file system, cygwin symbolic link does not work. -- Takashi Yano -- 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: vboxsharedfs - Too many levels of symbolic links
On 2021-12-05 04:54, Takashi Yano wrote:
On Tue, 30 Nov 2021 19:04:57 +0200
Oskar Skog wrote:
vboxsharedfs file systems no longer work. Any attempt to access will
result in "too many levels of symbolic links".
This only affects the VirtualBox shared folder, the Samba share works
just fine.
I tested with VirtualBox version 6.1.30.
In 64bit Windows10, for vbox shared path, GetFinalPathNameByHandleW()
returns path with trailing '\'. As a result, RtlEqualUnicodeString()
fails and tries to resolve symlink repeatedly.
For example, RtlEqualUnicodeString() compares \??\UNC\VBoxSrv\tmp and
\??\UNC\VBoxSrv\tmp\, then it fails.
This does not happen in 32bit Windows10. It seems that UNC path is not
treated as a symlink in 32bit Windows10. I am not sure why.
Therefore, I have applied a patch which stops to treat UNC path as a
symlink for testing as follows.
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index baf04ce89..31a96ca58 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -3490,6 +3490,9 @@ restart:
ret = GetFinalPathNameByHandleW (h, fpbuf, NT_MAX_PATH, 0);
if (ret)
{
+ if (wcsstr (fpbuf, L"?\\UNC\\") == fpbuf)
+ goto file_not_symlink;
+
UNICODE_STRING fpath;
RtlInitCountedUnicodeString (, fpbuf, ret * sizeof (WCHAR));
I have confirmed this patch fixes the issue. In addition, this patch
also resolves the issue:
https://cygwin.com/pipermail/cygwin/2021-December/250103.html
Is this the right thing?
I have tested the patch and it is now possible to access /cygdrive/z
again.
But if I create a symlink on that filesystem, it's not identified as a
symlink. Although, I don't know if this has ever worked as it is the
first time I've ever tested it, it probably hasn't ever worked (see
below).
user@DESKTOP-*** /cygdrive/z$ ln -s report.pdf test.pdf
user@DESKTOP-*** /cygdrive/z$ ls -l report.pdf test.pdf
-rw-r--r-- 1 user None 1454562 Nov 28 12:05 report.pdf
-rw-r--r-- 1 user None 34 Dec 5 16:36 test.pdf
user@DESKTOP-*** /cygdrive/z$ cat test.pdf
!▒▒report.pdfuser@DESKTOP-*** /cygdrive/z$
I think it's because "special" attributes don't work on VirtualBox
shared folders, I can't hide files in Explorer either.
So I don't think the patch has caused any regression here.
The samba share (Y:) works, just as it did before, symlinks work too.
(Sorry about the previous mail, I apparently suck at email.)
--
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
Fwd: vboxsharedfs - Too many levels of symbolic links
On 2021-12-05 04:54, Takashi Yano wrote:
In 64bit Windows10, for vbox shared path, GetFinalPathNameByHandleW()
returns path with trailing '\'. As a result, RtlEqualUnicodeString()
fails and tries to resolve symlink repeatedly.
For example, RtlEqualUnicodeString() compares \??\UNC\VBoxSrv\tmp and
\??\UNC\VBoxSrv\tmp\, then it fails.
This does not happen in 32bit Windows10. It seems that UNC path is not
treated as a symlink in 32bit Windows10. I am not sure why.
Therefore, I have applied a patch which stops to treat UNC path as a
symlink for testing as follows.
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index baf04ce89..31a96ca58 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -3490,6 +3490,9 @@ restart:
ret = GetFinalPathNameByHandleW (h, fpbuf, NT_MAX_PATH, 0);
if (ret)
{
+ if (wcsstr (fpbuf, L"?\\UNC\\") == fpbuf)
+ goto file_not_symlink;
+
UNICODE_STRING fpath;
RtlInitCountedUnicodeString (, fpbuf, ret * sizeof (WCHAR));
I have confirmed this patch fixes the issue. In addition, this patch
also resolves the issue:
https://cygwin.com/pipermail/cygwin/2021-December/250103.html
Is this the right thing?
-- Takashi Yano
I can confirm that the patch fixes the issue with VirtualBox shared
folders.
--
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: vboxsharedfs - Too many levels of symbolic links
On Tue, 30 Nov 2021 19:04:57 +0200
Oskar Skog wrote:
> vboxsharedfs file systems no longer work. Any attempt to access will
> result in "too many levels of symbolic links".
>
> This only affects the VirtualBox shared folder, the Samba share works
> just fine.
>
> Last time I updated (before today) was sometime before the 10th of
> September.
>
> MSYS2 has the same problem, but no one seems to have reported it to
> Cygwin:
> https://github.com/msys2/msys2-runtime/issues/58
>
>
> user@DESKTOP-*** ~$ ls /cygdrive/z
> ls: cannot access '/cygdrive/z': Too many levels of symbolic links
> user@DESKTOP-*** ~$ mount
> C:/Cygwin/bin on /usr/bin type ntfs (binary,auto)
> C:/Cygwin/lib on /usr/lib type ntfs (binary,auto)
> C:/Cygwin on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
> Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto)
> Z: on /cygdrive/z type vboxsharedfolderfs
> (binary,posix=0,user,noumount,auto)
> user@DESKTOP-*** ~$ uname -a
> CYGWIN_NT-10.0 DESKTOP-* 3.3.2(0.341/5/3) 2021-11-08 16:55 x86_64 Cygwin
Thanks for the report.
It seems that this happens only in 64bit Windoes10/11.
In 32bit Windows10:
$ ls -l /cygdrive/z
total 0
-rw-r--r-- 1 yano yano 0 Dec 3 22:16 testfile.txt
$ mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto)
$ uname -a
CYGWIN_NT-10.0 DESKTOP-HGUT5FP 3.3.2(0.341/5/3) 2021-11-08 16:51 i686 Cygwin
In 64bit Windows10:
$ ls -l /cygdrive/z
ls: /cygdrive/z: Too many levels of symbolic links
ls: cannot open directory '/cygdrive/z': Too many levels of symbolic links
$ mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto)
$ uname -a
CYGWIN_NT-10.0-WOW DESKTOP-CUHC1NV 3.3.2(0.341/5/3) 2021-11-08 16:51 i686 Cygwin
I tested with VirtualBox version 6.1.30.
In 64bit Windows10, for vbox shared path, GetFinalPathNameByHandleW()
returns path with trailing '\'. As a result, RtlEqualUnicodeString()
fails and tries to resolve symlink repeatedly.
For example, RtlEqualUnicodeString() compares \??\UNC\VBoxSrv\tmp and
\??\UNC\VBoxSrv\tmp\, then it fails.
This does not happen in 32bit Windows10. It seems that UNC path is not
treated as a symlink in 32bit Windows10. I am not sure why.
Therefore, I have applied a patch which stops to treat UNC path as a
symlink for testing as follows.
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index baf04ce89..31a96ca58 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -3490,6 +3490,9 @@ restart:
ret = GetFinalPathNameByHandleW (h, fpbuf, NT_MAX_PATH, 0);
if (ret)
{
+ if (wcsstr (fpbuf, L"?\\UNC\\") == fpbuf)
+ goto file_not_symlink;
+
UNICODE_STRING fpath;
RtlInitCountedUnicodeString (, fpbuf, ret * sizeof (WCHAR));
I have confirmed this patch fixes the issue. In addition, this patch
also resolves the issue:
https://cygwin.com/pipermail/cygwin/2021-December/250103.html
Is this the right thing?
--
Takashi Yano
--
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: vboxsharedfs - Too many levels of symbolic links
On Nov 30 19:04, Oskar Skog wrote: > vboxsharedfs file systems no longer work. Any attempt to access will > result in "too many levels of symbolic links". > > This only affects the VirtualBox shared folder, the Samba share works > just fine. > > Last time I updated (before today) was sometime before the 10th of > September. > > MSYS2 has the same problem, but no one seems to have reported it to > Cygwin: > https://github.com/msys2/msys2-runtime/issues/58 > > > user@DESKTOP-*** ~$ ls /cygdrive/z > ls: cannot access '/cygdrive/z': Too many levels of symbolic links > user@DESKTOP-*** ~$ mount > C:/Cygwin/bin on /usr/bin type ntfs (binary,auto) > C:/Cygwin/lib on /usr/lib type ntfs (binary,auto) > C:/Cygwin on / type ntfs (binary,auto) > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto) > Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) > Z: on /cygdrive/z type vboxsharedfolderfs > (binary,posix=0,user,noumount,auto) > user@DESKTOP-*** ~$ uname -a > CYGWIN_NT-10.0 DESKTOP-* 3.3.2(0.341/5/3) 2021-11-08 16:55 x86_64 Cygwin Somebody will have to debug this. From the MSYS issue it looks like the GetFinalPathNameByHandleW call results in some trouble, but the MSYS guys rather just disable code instead of trying to debug it and fixing the cause. "Somebody" would have to be somebody who can reproduce the issue. I'm neither using VirtualBox, nor AFS. I probably could test this if somebody gives me temporary access to an existing AFS FS somewhere, plus a short description how to connect. I guess it starts with "Install latest OpenAFS version x.y for Windows"... 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: vboxsharedfs - Too many levels of symbolic links
Same problem for me against AFS file system beyond 5 levels in the directory tree. Fell back to 3.2.0-1 (Cygwin) to resolve. None of the 3.3 versions worked (up to 3.3.2-1) -Original Message- From: Cygwin On Behalf Of Oskar Skog Sent: Tuesday, November 30, 2021 9:05 AM To: cygwin@cygwin.com Subject: vboxsharedfs - Too many levels of symbolic links Check twice before you click! This email originated from outside PNNL. vboxsharedfs file systems no longer work. Any attempt to access will result in "too many levels of symbolic links". This only affects the VirtualBox shared folder, the Samba share works just fine. Last time I updated (before today) was sometime before the 10th of September. MSYS2 has the same problem, but no one seems to have reported it to Cygwin: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmsys2%2Fmsys2-runtime%2Fissues%2F58data=04%7C01%7CPhilip.Gackle%40pnnl.gov%7Cc9ed5aca3b89499b931508d9b423ad0d%7Cd6faa5f90ae240338c0130048a38deeb%7C0%7C0%7C63773765066642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=FQ%2FLAAfIRvLXr7gL1iqVQkspgWXL2WY59FB8fvx8DqI%3Dreserved=0 user@DESKTOP-*** ~$ ls /cygdrive/z ls: cannot access '/cygdrive/z': Too many levels of symbolic links user@DESKTOP-*** ~$ mount C:/Cygwin/bin on /usr/bin type ntfs (binary,auto) C:/Cygwin/lib on /usr/lib type ntfs (binary,auto) C:/Cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto) Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto) user@DESKTOP-*** ~$ uname -a CYGWIN_NT-10.0 DESKTOP-* 3.3.2(0.341/5/3) 2021-11-08 16:55 x86_64 Cygwin -- Problem reports: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fproblems.htmldata=04%7C01%7CPhilip.Gackle%40pnnl.gov%7Cc9ed5aca3b89499b931508d9b423ad0d%7Cd6faa5f90ae240338c0130048a38deeb%7C0%7C0%7C63773765076597%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=OUOovyeBCPL1b6mSQOHHI3k0GBQEETJV71wPfhYUltU%3Dreserved=0 FAQ: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Ffaq%2Fdata=04%7C01%7CPhilip.Gackle%40pnnl.gov%7Cc9ed5aca3b89499b931508d9b423ad0d%7Cd6faa5f90ae240338c0130048a38deeb%7C0%7C0%7C63773765076597%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=8mQ%2FNyYJGT5J5P3pLOtu1FWQaoPWQIHZgXmfaeeI4WM%3Dreserved=0 Documentation: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fdocs.htmldata=04%7C01%7CPhilip.Gackle%40pnnl.gov%7Cc9ed5aca3b89499b931508d9b423ad0d%7Cd6faa5f90ae240338c0130048a38deeb%7C0%7C0%7C63773765076597%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=l8lbrBZTWc7wJIsPLKI%2Bvsj4zzW%2Fi9RNFNvXQge%2B%2FCI%3Dreserved=0 Unsubscribe info: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fml%2F%23unsubscribe-simpledata=04%7C01%7CPhilip.Gackle%40pnnl.gov%7Cc9ed5aca3b89499b931508d9b423ad0d%7Cd6faa5f90ae240338c0130048a38deeb%7C0%7C0%7C63773765076597%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=wtlkvSXvzCzYKQlO2voUxYgq7DoiQ5Lte08rLrAw9m4%3Dreserved=0 -- 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
vboxsharedfs - Too many levels of symbolic links
vboxsharedfs file systems no longer work. Any attempt to access will result in "too many levels of symbolic links". This only affects the VirtualBox shared folder, the Samba share works just fine. Last time I updated (before today) was sometime before the 10th of September. MSYS2 has the same problem, but no one seems to have reported it to Cygwin: https://github.com/msys2/msys2-runtime/issues/58 user@DESKTOP-*** ~$ ls /cygdrive/z ls: cannot access '/cygdrive/z': Too many levels of symbolic links user@DESKTOP-*** ~$ mount C:/Cygwin/bin on /usr/bin type ntfs (binary,auto) C:/Cygwin/lib on /usr/lib type ntfs (binary,auto) C:/Cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto) Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto) user@DESKTOP-*** ~$ uname -a CYGWIN_NT-10.0 DESKTOP-* 3.3.2(0.341/5/3) 2021-11-08 16:55 x86_64 Cygwin -- 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: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Am 24.03.2021 um 21:58 schrieb Ken Brown: On 3/24/2021 2:55 PM, Hans-Bernhard Bröker wrote: Am 23.03.2021 um 10:30 schrieb Corinna Vinschen via Cygwin-patches: > On Mar 22 22:54, Hans-Bernhard Bröker wrote: >> Am 22.03.2021 um 16:22 schrieb Johannes Schindelin: It's what WSL Debian creates when I 'ln -s' inside its own filesystem. Windows' own "dir" command shows it as 22.03.2021 22:34 link_to_a [...] But it cannot do anything else with it. Even fsutil doesn't work on that thing: C:\prg\test>fsutil reparsePoint query \\wsl$\Debian\home\hbbro Fehler: Unzulässige Funktion. Are you running WSL1 or WSL2? To the best of my knowledge it's WSL1. I have WSL1, and the stat command such as the one you tried fails in the same way as yours. Nevertheless, a symlink created under WSL is indeed recognized as such by Cygwin. I verified this as follows: 1. Within WSL, $ ln -s foo mysymlink $ cp -a mysymlink /mnt/c/cygwin64/tmp Here it gets a bit weird. The result of that procedure depends on whether the link target, 'foo', exists in cygwin64/tmp prior to running the above commands. If 'foo' exists, the copy of the symlink becomes a Windows native symlink (reparse point class 0xa00c). If it doesn't the copy turns into a reparse point of class 0xa01d, which 'fsutil reparsepoint query' decodes as "name replacement", Cygwin as a (broken) symlink, and 'dir' lists as . In other words, a WSL symlink. It's quite strange that copying a native WSL1 symlink from inside WSL's own file system out into the Windows side of things does _not_ always yield an identical copy. Some layer sitting between WSL and the Windows file system may modify the copy in flight. The same difference applies if, instead of copying an existing symlink, you just have WSL create one directly in the Windows tree, i.e. cd /mnt/c/cygwin64/tmp rm a b touch a ln -s a la ln -s b lb touch b yields a Windows symlink for 'la', and a WSL symlink for 'lb'.
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
On 3/24/2021 2:55 PM, Hans-Bernhard Bröker wrote: Am 23.03.2021 um 10:30 schrieb Corinna Vinschen via Cygwin-patches: > On Mar 22 22:54, Hans-Bernhard Bröker wrote: >> Am 22.03.2021 um 16:22 schrieb Johannes Schindelin: >>> One of those under-documented reparse point types is the WSL symbolic >>> link, which you will notice are supported in Cygwin, removing quite some >>> sway from your argument... >> >> I notice no such thing right now, running the currently available release >> version 3.1.7: >> >> stat: cannot stat '//wsl$/Debian/home/hbbro/link_to_a': Input/output error > > What type of WSL symlink is that? It's what WSL Debian creates when I 'ln -s' inside its own filesystem. Windows' own "dir" command shows it as 22.03.2021 22:34 link_to_a [...] But it cannot do anything else with it. Even fsutil doesn't work on that thing: C:\prg\test>fsutil reparsePoint query \\wsl$\Debian\home\hbbro Fehler: Unzulässige Funktion. Are you running WSL1 or WSL2? I have WSL1, and the stat command such as the one you tried fails in the same way as yours. Nevertheless, a symlink created under WSL is indeed recognized as such by Cygwin. I verified this as follows: 1. Within WSL, $ ln -s foo mysymlink $ cp -a mysymlink /mnt/c/cygwin64/tmp 2. Within Cygwin, $ stat /tmp/mysymlink File: /tmp/mysymlink -> foo Size: 3 Blocks: 0 IO Block: 65536 symbolic link Device: 74d6767bh/1960212091d Inode: 25614222880728371 Links: 1 Access: (0777/lrwxrwxrwx) Uid: (197609/ kbrown) Gid: (197121/None) Access: 2021-03-24 16:25:50.729219700 -0400 Modify: 2021-03-24 16:25:50.729219700 -0400 Change: 2021-03-24 16:27:13.979376200 -0400 Birth: 2021-03-24 16:27:13.979376200 -0400 3. I then ran the stat command under gdb with a breakpoint at check_reparse_point_target and verified that Cygwin recognized /tmp/mysymlink as a WSL symlink (IO_REPARSE_TAG_LX_SYMLINK). Someone with WSL2 should try a similar experiment to make sure that the symlink representation as a reparse point hasn't changed. As to the failure of the stat command that you tried, I suspect it is related to the '\\wsl$' magic rather than anything to do with the symlink itself. If you run that stat command under strace, you'll see that Cygwin calls NtCreateFile (\??\UNC\wsl$\...), which succeeds, and then calls NtFsControlFile(FSCTL_GET_REPARSE_POINT), which fails with STATUS_NOT_IMPLEMENTED. Ken
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Am 23.03.2021 um 10:30 schrieb Corinna Vinschen via Cygwin-patches: > On Mar 22 22:54, Hans-Bernhard Bröker wrote: >> Am 22.03.2021 um 16:22 schrieb Johannes Schindelin: >>> One of those under-documented reparse point types is the WSL symbolic >>> link, which you will notice are supported in Cygwin, removing quite some >>> sway from your argument... >> >> I notice no such thing right now, running the currently available release >> version 3.1.7: >> >> stat: cannot stat '//wsl$/Debian/home/hbbro/link_to_a': Input/output error > > What type of WSL symlink is that? It's what WSL Debian creates when I 'ln -s' inside its own filesystem. Windows' own "dir" command shows it as 22.03.2021 22:34 link_to_a [...] But it cannot do anything else with it. Even fsutil doesn't work on that thing: C:\prg\test>fsutil reparsePoint query \\wsl$\Debian\home\hbbro Fehler: Unzulässige Funktion.
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
On Mar 22 22:54, Hans-Bernhard Bröker wrote: > Am 22.03.2021 um 16:22 schrieb Johannes Schindelin: > > One of those under-documented reparse point types is the WSL symbolic > > link, which you will notice are supported in Cygwin, removing quite some > > sway from your argument... > > I notice no such thing right now, running the currently available release > version 3.1.7: > > stat: cannot stat '//wsl$/Debian/home/hbbro/link_to_a': Input/output error What type of WSL symlink is that? Cygwin reads WSL 1 symlinks(*) and creates them by default in symlink(2) cals since Cygwin 3.1.5. (*) IO_REPARSE_TAG_LX_SYMLINK 0xa01d Corinna
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Am 22.03.2021 um 16:22 schrieb Johannes Schindelin: On Mon, 15 Mar 2021, Hans-Bernhard Bröker wrote: Am 15.03.2021 um 04:19 schrieb Johannes Schindelin via Cygwin-patches: That argument might hold more sway if Windows itself didn't quite so completely hide that information from users, too. "So completely"? It at least executes them, and it does offer you to turn them aliases on and off (see https://www.tenforums.com/tutorials/102096-manage-app-execution-aliases-windows-10-a.html) That's a completely different piece of information than what you want Cygwin to show. Granted, the user interface has a lot of room for improvement, but if you are dead set on finding out what, say, that `idle.exe` app execution alias refers to, you can go to `Settings>Apps>Apps & features>App execution aliases` and find out that it is owned by the Python 3.7 package. Knowing which package that thing came from has essentially nothing to do with what its interpretation as a symlink would look like. Apples and Oranges. The `fsutil` program, contrary to your claim, is available without WSL: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil And that very page tells me, in a big "Notice" blurb: You must enable Windows Subsystem for Linux before you can run fsutil. Run the following command as Administrator in PowerShell to enable this optional feature: One of those under-documented reparse point types is the WSL symbolic link, which you will notice are supported in Cygwin, removing quite some sway from your argument... I notice no such thing right now, running the currently available release version 3.1.7: stat: cannot stat '//wsl$/Debian/home/hbbro/link_to_a': Input/output error [other commands that want to show more than just the name behave equivalently] Links made by WSL directly on a Windows filesystem are understood by Cygwin. But that's because WSL uses Windows symlinks in that case. Microsoft could almost certainly just have used a symlink to implement this rather trivial feature. But for some reason they apparently didn't care to explain anywhere, they chose to wildly overcomplicate it, inventing a completly type of reparse point. So for what it's worth, that thing _is_not_a_symlink_. Pretending it is one is bound to cause more problems than it solves. Well, that's funny: you are talking to one Cygwin user who needs to see it. So I feel a bit ignored by you there. All conclusions based on a single example are wrong.
[PATCH v2 1/2] Treat Windows Store's "app execution aliases" as symbolic links
When the Windows Store version of Python is installed, so-called "app
execution aliases" are put into the `PATH`. These are reparse points
under the hood, with an undocumented format.
We do know a bit about this format, though, as per the excellent analysis:
https://www.tiraniddo.dev/2019/09/overview-of-windows-execution-aliases.html
The first 4 bytes is the reparse tag, in this case it's
0x801B which is documented in the Windows SDK as
IO_REPARSE_TAG_APPEXECLINK. Unfortunately there doesn't seem to
be a corresponding structure, but with a bit of reverse
engineering we can work out the format is as follows:
Version: <4 byte integer>
Package ID:
Entry Point:
Executable:
Application Type:
Let's treat them as symbolic links. For example, in this developer's
setup, this will result in the following nice output:
$ cd $LOCALAPPDATA/Microsoft/WindowsApps/
$ ls -l python3.exe
lrwxrwxrwx 1 me 4096 105 Aug 23 2020 python3.exe -> '/c/Program
Files/WindowsApps/PythonSoftwareFoundation.Python.3.7_3.7.2544.0_x64__qbz5n2kfra8p0/python.exe'
Signed-off-by: Johannes Schindelin
---
winsup/cygwin/path.cc | 40
1 file changed, 40 insertions(+)
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index f3b9913bd0..56834963a2 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2439,6 +2439,22 @@ symlink_info::check_sysfile (HANDLE h)
return res;
}
+typedef struct _REPARSE_APPEXECLINK_BUFFER
+{
+ DWORD ReparseTag;
+ WORD ReparseDataLength;
+ WORD Reserved;
+ struct {
+DWORD Version; /* Take member name with a grain of salt. */
+WCHAR Strings[1];/* Four serialized, NUL-terminated WCHAR strings:
+ - Package ID
+ - Entry Point
+ - Executable Path
+ - Application Type
+ We're only interested in the Executable Path */
+ } AppExecLinkReparseBuffer;
+} REPARSE_APPEXECLINK_BUFFER,*PREPARSE_APPEXECLINK_BUFFER;
+
static bool
check_reparse_point_string (PUNICODE_STRING subst)
{
@@ -2538,6 +2554,30 @@ check_reparse_point_target (HANDLE h, bool remote,
PREPARSE_DATA_BUFFER rp,
if (check_reparse_point_string (psymbuf))
return PATH_SYMLINK | PATH_REP;
}
+ else if (!remote && rp->ReparseTag == IO_REPARSE_TAG_APPEXECLINK)
+{
+ /* App execution aliases are commonly used by Windows Store apps. */
+ PREPARSE_APPEXECLINK_BUFFER rpl = (PREPARSE_APPEXECLINK_BUFFER) rp;
+ WCHAR *buf = rpl->Strings;
+ DWORD size = rp->ReparseDataLength / sizeof (WCHAR), n;
+
+ /* It seems that app execution aliases have a payload of four
+NUL-separated wide string: package id, entry point, executable
+and application type. We're interested in the executable. */
+ for (int i = 0; i < 3 && size > 0; i++)
+ {
+ n = wcsnlen (buf, size - 1);
+ if (i == 2 && n > 0 && n < size)
+ {
+ RtlInitCountedUnicodeString (psymbuf, buf, n * sizeof (WCHAR));
+ return PATH_SYMLINK | PATH_REP;
+ }
+ if (i == 2)
+ break;
+ buf += n + 1;
+ size -= n + 1;
+ }
+}
else if (rp->ReparseTag == IO_REPARSE_TAG_LX_SYMLINK)
{
/* WSL symlink. Problem: We have to convert the path to UTF-16 for
--
2.31.0
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Hi Hans-Bernhard, On Mon, 15 Mar 2021, Hans-Bernhard Bröker wrote: > Am 15.03.2021 um 04:19 schrieb Johannes Schindelin via Cygwin-patches: > > > On Sat, 13 Mar 2021, Joe Lowe wrote: > > > > > I agree on the usefulness to the user of showing appexec target > > > executable as symlink target. But I am uncertain about the effect on > > > code. > > > > Maybe. But I am concerned about the effect of not being able to do > > anything useful with app execution aliases in the first place. > > That argument might hold more sway if Windows itself didn't quite so > completely hide that information from users, too. "So completely"? It at least executes them, and it does offer you to turn them aliases on and off (see https://www.tenforums.com/tutorials/102096-manage-app-execution-aliases-windows-10-a.html) Granted, the user interface has a lot of room for improvement, but if you are dead set on finding out what, say, that `idle.exe` app execution alias refers to, you can go to `Settings>Apps>Apps & features>App execution aliases` and find out that it is owned by the Python 3.7 package. That does not give you the path, but it does give you way more information than you claimed Windows would offer to you. > I found only one Windows native tool that will even show _any_ kind of > information about these reparse points: fsutil. That is a) only available as > part of the highly optional WSL feature and b) only gives you a hexdump of the > actual data, without any meaningful interpretation. The `fsutil` program, contrary to your claim, is available without WSL: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil And yes, for under-documented reparse points, the tool gives you only a hexdump. One of those under-documented reparse point types is the WSL symbolic link, which you will notice are supported in Cygwin, removing quite some sway from your argument... > For something that Windows itself gives the "no user servicable parts inside" > treatment to the extent it does for these reparse points, I rather doubt that > Cygwin users really _need_ to see it. Well, that's funny: you are talking to one Cygwin user who needs to see it. So I feel a bit ignored by you there. Ciao, Johannes
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Hi Johannes,
I'm not opposed to treat these applinks as symlinks. I have a
suggestion and a style nit, though.
On Mar 12 16:11, Johannes Schindelin via Cygwin-patches wrote:
> When the Windows Store version of Python is installed, so-called "app
> execution aliases" are put into the `PATH`. These are reparse points
> under the hood, with an undocumented format.
>
> We do know a bit about this format, though, as per the excellent analysis:
> https://www.tiraniddo.dev/2019/09/overview-of-windows-execution-aliases.html
>
> The first 4 bytes is the reparse tag, in this case it's
> 0x801B which is documented in the Windows SDK as
> IO_REPARSE_TAG_APPEXECLINK. Unfortunately there doesn't seem to
> be a corresponding structure, but with a bit of reverse
> engineering we can work out the format is as follows:
>
> Version: <4 byte integer>
> Package ID:
> Entry Point:
> Executable:
> Application Type:
Given we know this layout, what about introducing a matching struct,
like I did for REPARSE_LX_SYMLINK_BUFFER, for instructional purposes?
I. e.
typedef struct _REPARSE_APPEXECLINK_BUFFER
{
DWORD ReparseTag;
WORD ReparseDataLength;
WORD Reserved;
struct {
DWORD Version; /* Take member name with a grain of salt. */
WCHAR Strings[1];/* Four serialized, NUL-terminated WCHAR strings:
- Package ID
- Entry Point
- Executable Path
- Application Type
We're only interested in the Executable Path */
} AppExecLinkReparseBuffer;
} REPARSE_APPEXECLINK_BUFFER,*PREPARSE_APPEXECLINK_BUFFER;
> + else if (!remote && rp->ReparseTag == IO_REPARSE_TAG_APPEXECLINK)
> +{
> + /* App execution aliases are commonly used by Windows Store apps. */
> + WCHAR *buf = (WCHAR *)(rp->GenericReparseBuffer.DataBuffer + 4);
Analogue:
PREPARSE_APPEXECLINK_BUFFER rpl = (PREPARSE_APPEXECLINK_BUFFER) rp;
WCHAR *buf = rpl->AppExecLinkReparseBuffer.Strings;
Maybe use 'str' or 'strp' here, instead of buf?
> + for (int i = 0; i < 3 && size > 0; i++)
> +{
> + n = wcsnlen (buf, size - 1);
> + if (i == 2 && n > 0 && n < size)
> + {
> + RtlInitCountedUnicodeString (psymbuf, buf, n * sizeof(WCHAR));
^^^
space
Thanks,
Corinna
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Am 15.03.2021 um 04:19 schrieb Johannes Schindelin via Cygwin-patches: Hi Joe, On Sat, 13 Mar 2021, Joe Lowe wrote: I agree on the usefulness to the user of showing appexec target executable as symlink target. But I am uncertain about the effect on code. Maybe. But I am concerned about the effect of not being able to do anything useful with app execution aliases in the first place. That argument might hold more sway if Windows itself didn't quite so completely hide that information from users, too. I found only one Windows native tool that will even show _any_ kind of information about these reparse points: fsutil. That is a) only available as part of the highly optional WSL feature and b) only gives you a hexdump of the actual data, without any meaningful interpretation. For something that Windows itself gives the "no user servicable parts inside" treatment to the extent it does for these reparse points, I rather doubt that Cygwin users really _need_ to see it.
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Hi Joe, On Sat, 13 Mar 2021, Joe Lowe wrote: > I agree on the usefulness to the user of showing appexec target executable as > symlink target. But I am uncertain about the effect on code. Maybe. But I am concerned about the effect of not being able to do anything useful with app execution aliases in the first place. I'd rather have them represented as if they were symlinks (even if that is not 100% accurate) than not being able to even answer the very simple (and obvious!) question: where does this thing point to? > One example: Any app that is able to archive/copy posix symlinks will convert > the appexec to a symlink and silently drop the appexec data. Whether this is a > significant issue depends on if most/all relevent store apps function the same > when the executable is exec-ed directly vs via the appexec link. I do have bad news for you: WSL symlinks are _already_ supported (https://github.com/cygwin/cygwin/blob/d10d0d9b03f85/winsup/cygwin/path.cc#L2561-L2630), and just like app execution aliases, they are not faithfully recreated. Likewise junctions: https://github.com/cygwin/cygwin/blob/d10d0d9b03f85/winsup/cygwin/path.cc#L2540-L2560 This suggests to me that the endeavor to have archive/copy programs based on Cygwin's runtime work as you expect is doomed from the start. > Another example: Much code exists in the field that intentionally detects > symlinks, dereferences, and works directly on the target. This may not be an > issue, if most/all relevent store apps function the same when the executable > is exec-ed directly vs via the appexec link. As far as I can tell, the only thing you _can_ do with an app execution alias (apart from creating/deleting it) is to execute it. If you try to read or write them, you get a "Permission denied". Their intended use case seems to be the same as Debian Alternatives (https://wiki.debian.org/DebianAlternatives) which _are_ implemented as symbolic links. So I still think that the best we can do with app execution aliases in Cygwin is to display them as if they were plain old symbolic links. Ciao, Johannes > > > Joe L. > > > > On 3/13/2021 4:21 PM, Johannes Schindelin wrote: > > Hi Joe, > > > > On Fri, 12 Mar 2021, Joe Lowe wrote: > > > > > I am skeptical about this patch (part 1), interposing appexec reparse > > > point > > > data as symlinks for cygwin applications. > > > > > > The appexec reparse point data is essentially an extended attribute > > > holding > > > data that is used by CreateProcess(), more like a windows .lnk file or an > > > X11 > > > .desktop file, not like a posix symlink. M$ just chose an unnecessarily > > > obtuse > > > way to store the files data. This reminds me of old Macintosh zero length > > > font > > > files. > > > > The obvious difference being that you cannot read those 0-length files. > > And you _can_ determine the target from reading .lnk or .desktop files. > > > > > The useful function of the patch would seem to be as a way to display a > > > portion of the data in shell directory listings for the user. I suggest > > > this > > > function is better provided by updated application code. > > > > I find your argument unconvincing. > > > > For all practical purposes, users are likely to want to treat app > > execution aliases as if they were symbolic links. > > > > If users want to know more about the app execution alias than just the > > path of the actual `.exe` (and that is a rather huge if), _then_ I would > > buy your argument that it should be queried via application code. > > > > But for the common case of reading the corresponding `.exe` or accessing > > the path? Why should we follow your suggestion and keep making it really > > hard for users to get to that information? I really don't get it. > > > > Ciao, > > Johannes > > > > > > > > > > > The patch part 2 seems entirely appropriate. > > > > > > > > > Joe L. > > > > > > > > > On 2021-03-12 07:11, Johannes Schindelin via Cygwin-patches wrote: > > > > When the Windows Store version of Python is installed, so-called "app > > > > execution aliases" are put into the `PATH`. These are reparse points > > > > under the hood, with an undocumented format. > > > > > > > > We do know a bit about this format, though, as per the excellent > > > > analysis: > > > > https://www.tiraniddo.dev/2019/09/overview-of-windows-execution-aliases.html > > > > > > > > The first 4 bytes is the reparse tag, in this ca
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
On Mar 13 19:41, Joe Lowe via Cygwin-patches wrote: > Hi Johannes, > > I agree on the usefulness to the user of showing appexec target executable > as symlink target. But I am uncertain about the effect on code. > > One example: Any app that is able to archive/copy posix symlinks will > convert the appexec to a symlink and silently drop the appexec data. Whether > this is a significant issue depends on if most/all relevent store apps > function the same when the executable is exec-ed directly vs via the appexec > link. You won't get a sufficent, POSIX-like handling one way or the other. Handling them as files will not allow correct archiving either, because the reparse point data required to restore them correctly to work in Windows won't be archived anyway. There's only so much we can do in the Windows environment. ¯\_(ツ)_/¯ I'd just like to postpone this patch to get 3.2.0 out. I'll add that patch to the inevitable 3.2.1 release, given the massive testing of 3.2.0-0.1 on the Cygwin ML... Thanks, Corinna
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Hi Johannes,
I agree on the usefulness to the user of showing appexec target
executable as symlink target. But I am uncertain about the effect on code.
One example: Any app that is able to archive/copy posix symlinks will
convert the appexec to a symlink and silently drop the appexec data.
Whether this is a significant issue depends on if most/all relevent
store apps function the same when the executable is exec-ed directly vs
via the appexec link.
Another example: Much code exists in the field that intentionally
detects symlinks, dereferences, and works directly on the target. This
may not be an issue, if most/all relevent store apps function the same
when the executable is exec-ed directly vs via the appexec link.
Joe L.
On 3/13/2021 4:21 PM, Johannes Schindelin wrote:
Hi Joe,
On Fri, 12 Mar 2021, Joe Lowe wrote:
I am skeptical about this patch (part 1), interposing appexec reparse point
data as symlinks for cygwin applications.
The appexec reparse point data is essentially an extended attribute holding
data that is used by CreateProcess(), more like a windows .lnk file or an X11
.desktop file, not like a posix symlink. M$ just chose an unnecessarily obtuse
way to store the files data. This reminds me of old Macintosh zero length font
files.
The obvious difference being that you cannot read those 0-length files.
And you _can_ determine the target from reading .lnk or .desktop files.
The useful function of the patch would seem to be as a way to display a
portion of the data in shell directory listings for the user. I suggest this
function is better provided by updated application code.
I find your argument unconvincing.
For all practical purposes, users are likely to want to treat app
execution aliases as if they were symbolic links.
If users want to know more about the app execution alias than just the
path of the actual `.exe` (and that is a rather huge if), _then_ I would
buy your argument that it should be queried via application code.
But for the common case of reading the corresponding `.exe` or accessing
the path? Why should we follow your suggestion and keep making it really
hard for users to get to that information? I really don't get it.
Ciao,
Johannes
The patch part 2 seems entirely appropriate.
Joe L.
On 2021-03-12 07:11, Johannes Schindelin via Cygwin-patches wrote:
When the Windows Store version of Python is installed, so-called "app
execution aliases" are put into the `PATH`. These are reparse points
under the hood, with an undocumented format.
We do know a bit about this format, though, as per the excellent analysis:
https://www.tiraniddo.dev/2019/09/overview-of-windows-execution-aliases.html
The first 4 bytes is the reparse tag, in this case it's
0x801B which is documented in the Windows SDK as
IO_REPARSE_TAG_APPEXECLINK. Unfortunately there doesn't seem to
be a corresponding structure, but with a bit of reverse
engineering we can work out the format is as follows:
Version: <4 byte integer>
Package ID:
Entry Point:
Executable:
Application Type:
Let's treat them as symbolic links. For example, in this developer's
setup, this will result in the following nice output:
$ cd $LOCALAPPDATA/Microsoft/WindowsApps/
$ ls -l python3.exe
lrwxrwxrwx 1 me 4096 105 Aug 23 2020 python3.exe -> '/c/Program
Files/WindowsApps/PythonSoftwareFoundation.Python.3.7_3.7.2544.0_x64__qbz5n2kfra8p0/python.exe'
Signed-off-by: Johannes Schindelin
---
winsup/cygwin/path.cc | 24
1 file changed, 24 insertions(+)
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index f3b9913bd0..63f377efb1 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2538,6 +2538,30 @@ check_reparse_point_target (HANDLE h, bool remote,
PREPARSE_DATA_BUFFER rp,
if (check_reparse_point_string (psymbuf))
return PATH_SYMLINK | PATH_REP;
}
+ else if (!remote && rp->ReparseTag == IO_REPARSE_TAG_APPEXECLINK)
+{
+ /* App execution aliases are commonly used by Windows Store apps. */
+ WCHAR *buf = (WCHAR *)(rp->GenericReparseBuffer.DataBuffer + 4);
+ DWORD size = rp->ReparseDataLength / sizeof(WCHAR), n;
+
+ /*
+ It seems that app execution aliases have a payload of four
+NUL-separated wide string: package id, entry point, executable
+and application type. We're interested in the executable. */
+ for (int i = 0; i < 3 && size > 0; i++)
+{
+ n = wcsnlen (buf, size - 1);
+ if (i == 2 && n > 0 && n < size)
+ {
+ RtlInitCountedUnicodeString (psymbuf, buf, n * sizeof(WCHAR));
+ return PATH_SYMLINK | PATH_REP;
+ }
+ if (i == 2)
+ break;
+ buf += n + 1;
+ size -= n + 1;
+ }
+}
else if (rp->ReparseTag == IO_REPARSE_TAG_LX_SYMLINK)
{
/* WSL symlink. Problem: We have to convert the path to UTF-16 for
--
2.30.2
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Hi Joe,
On Fri, 12 Mar 2021, Joe Lowe wrote:
> I am skeptical about this patch (part 1), interposing appexec reparse point
> data as symlinks for cygwin applications.
>
> The appexec reparse point data is essentially an extended attribute holding
> data that is used by CreateProcess(), more like a windows .lnk file or an X11
> .desktop file, not like a posix symlink. M$ just chose an unnecessarily obtuse
> way to store the files data. This reminds me of old Macintosh zero length font
> files.
The obvious difference being that you cannot read those 0-length files.
And you _can_ determine the target from reading .lnk or .desktop files.
> The useful function of the patch would seem to be as a way to display a
> portion of the data in shell directory listings for the user. I suggest this
> function is better provided by updated application code.
I find your argument unconvincing.
For all practical purposes, users are likely to want to treat app
execution aliases as if they were symbolic links.
If users want to know more about the app execution alias than just the
path of the actual `.exe` (and that is a rather huge if), _then_ I would
buy your argument that it should be queried via application code.
But for the common case of reading the corresponding `.exe` or accessing
the path? Why should we follow your suggestion and keep making it really
hard for users to get to that information? I really don't get it.
Ciao,
Johannes
>
>
> The patch part 2 seems entirely appropriate.
>
>
> Joe L.
>
>
> On 2021-03-12 07:11, Johannes Schindelin via Cygwin-patches wrote:
> > When the Windows Store version of Python is installed, so-called "app
> > execution aliases" are put into the `PATH`. These are reparse points
> > under the hood, with an undocumented format.
> >
> > We do know a bit about this format, though, as per the excellent analysis:
> > https://www.tiraniddo.dev/2019/09/overview-of-windows-execution-aliases.html
> >
> > The first 4 bytes is the reparse tag, in this case it's
> > 0x801B which is documented in the Windows SDK as
> > IO_REPARSE_TAG_APPEXECLINK. Unfortunately there doesn't seem to
> > be a corresponding structure, but with a bit of reverse
> > engineering we can work out the format is as follows:
> >
> > Version: <4 byte integer>
> > Package ID:
> > Entry Point:
> > Executable:
> > Application Type:
> >
> > Let's treat them as symbolic links. For example, in this developer's
> > setup, this will result in the following nice output:
> >
> > $ cd $LOCALAPPDATA/Microsoft/WindowsApps/
> >
> > $ ls -l python3.exe
> > lrwxrwxrwx 1 me 4096 105 Aug 23 2020 python3.exe -> '/c/Program
> >
> > Files/WindowsApps/PythonSoftwareFoundation.Python.3.7_3.7.2544.0_x64__qbz5n2kfra8p0/python.exe'
> >
> > Signed-off-by: Johannes Schindelin
> > ---
> > winsup/cygwin/path.cc | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
> > index f3b9913bd0..63f377efb1 100644
> > --- a/winsup/cygwin/path.cc
> > +++ b/winsup/cygwin/path.cc
> > @@ -2538,6 +2538,30 @@ check_reparse_point_target (HANDLE h, bool remote,
> > PREPARSE_DATA_BUFFER rp,
> > if (check_reparse_point_string (psymbuf))
> >return PATH_SYMLINK | PATH_REP;
> > }
> > + else if (!remote && rp->ReparseTag == IO_REPARSE_TAG_APPEXECLINK)
> > +{
> > + /* App execution aliases are commonly used by Windows Store apps. */
> > + WCHAR *buf = (WCHAR *)(rp->GenericReparseBuffer.DataBuffer + 4);
> > + DWORD size = rp->ReparseDataLength / sizeof(WCHAR), n;
> > +
> > + /*
> > + It seems that app execution aliases have a payload of four
> > +NUL-separated wide string: package id, entry point, executable
> > +and application type. We're interested in the executable. */
> > + for (int i = 0; i < 3 && size > 0; i++)
> > +{
> > + n = wcsnlen (buf, size - 1);
> > + if (i == 2 && n > 0 && n < size)
> > + {
> > + RtlInitCountedUnicodeString (psymbuf, buf, n * sizeof(WCHAR));
> > + return PATH_SYMLINK | PATH_REP;
> > + }
> > + if (i == 2)
> > + break;
> > + buf += n + 1;
> > + size -= n + 1;
> > + }
> > +}
> > else if (rp->ReparseTag == IO_REPARSE_TAG_LX_SYMLINK)
> > {
> > /* WSL symlink. Problem: We have to convert the path to UTF-16 for
> > --
> > 2.30.2
> >
>
>
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
I am skeptical about this patch (part 1), interposing appexec reparse
point data as symlinks for cygwin applications.
The appexec reparse point data is essentially an extended attribute
holding data that is used by CreateProcess(), more like a windows .lnk
file or an X11 .desktop file, not like a posix symlink. M$ just chose an
unnecessarily obtuse way to store the files data. This reminds me of old
Macintosh zero length font files.
The useful function of the patch would seem to be as a way to display a
portion of the data in shell directory listings for the user. I suggest
this function is better provided by updated application code.
The patch part 2 seems entirely appropriate.
Joe L.
On 2021-03-12 07:11, Johannes Schindelin via Cygwin-patches wrote:
When the Windows Store version of Python is installed, so-called "app
execution aliases" are put into the `PATH`. These are reparse points
under the hood, with an undocumented format.
We do know a bit about this format, though, as per the excellent analysis:
https://www.tiraniddo.dev/2019/09/overview-of-windows-execution-aliases.html
The first 4 bytes is the reparse tag, in this case it's
0x801B which is documented in the Windows SDK as
IO_REPARSE_TAG_APPEXECLINK. Unfortunately there doesn't seem to
be a corresponding structure, but with a bit of reverse
engineering we can work out the format is as follows:
Version: <4 byte integer>
Package ID:
Entry Point:
Executable:
Application Type:
Let's treat them as symbolic links. For example, in this developer's
setup, this will result in the following nice output:
$ cd $LOCALAPPDATA/Microsoft/WindowsApps/
$ ls -l python3.exe
lrwxrwxrwx 1 me 4096 105 Aug 23 2020 python3.exe -> '/c/Program
Files/WindowsApps/PythonSoftwareFoundation.Python.3.7_3.7.2544.0_x64__qbz5n2kfra8p0/python.exe'
Signed-off-by: Johannes Schindelin
---
winsup/cygwin/path.cc | 24
1 file changed, 24 insertions(+)
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index f3b9913bd0..63f377efb1 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2538,6 +2538,30 @@ check_reparse_point_target (HANDLE h, bool remote,
PREPARSE_DATA_BUFFER rp,
if (check_reparse_point_string (psymbuf))
return PATH_SYMLINK | PATH_REP;
}
+ else if (!remote && rp->ReparseTag == IO_REPARSE_TAG_APPEXECLINK)
+{
+ /* App execution aliases are commonly used by Windows Store apps. */
+ WCHAR *buf = (WCHAR *)(rp->GenericReparseBuffer.DataBuffer + 4);
+ DWORD size = rp->ReparseDataLength / sizeof(WCHAR), n;
+
+ /*
+ It seems that app execution aliases have a payload of four
+NUL-separated wide string: package id, entry point, executable
+and application type. We're interested in the executable. */
+ for (int i = 0; i < 3 && size > 0; i++)
+{
+ n = wcsnlen (buf, size - 1);
+ if (i == 2 && n > 0 && n < size)
+ {
+ RtlInitCountedUnicodeString (psymbuf, buf, n * sizeof(WCHAR));
+ return PATH_SYMLINK | PATH_REP;
+ }
+ if (i == 2)
+ break;
+ buf += n + 1;
+ size -= n + 1;
+ }
+}
else if (rp->ReparseTag == IO_REPARSE_TAG_LX_SYMLINK)
{
/* WSL symlink. Problem: We have to convert the path to UTF-16 for
--
2.30.2
[PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
When the Windows Store version of Python is installed, so-called "app
execution aliases" are put into the `PATH`. These are reparse points
under the hood, with an undocumented format.
We do know a bit about this format, though, as per the excellent analysis:
https://www.tiraniddo.dev/2019/09/overview-of-windows-execution-aliases.html
The first 4 bytes is the reparse tag, in this case it's
0x801B which is documented in the Windows SDK as
IO_REPARSE_TAG_APPEXECLINK. Unfortunately there doesn't seem to
be a corresponding structure, but with a bit of reverse
engineering we can work out the format is as follows:
Version: <4 byte integer>
Package ID:
Entry Point:
Executable:
Application Type:
Let's treat them as symbolic links. For example, in this developer's
setup, this will result in the following nice output:
$ cd $LOCALAPPDATA/Microsoft/WindowsApps/
$ ls -l python3.exe
lrwxrwxrwx 1 me 4096 105 Aug 23 2020 python3.exe -> '/c/Program
Files/WindowsApps/PythonSoftwareFoundation.Python.3.7_3.7.2544.0_x64__qbz5n2kfra8p0/python.exe'
Signed-off-by: Johannes Schindelin
---
winsup/cygwin/path.cc | 24
1 file changed, 24 insertions(+)
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index f3b9913bd0..63f377efb1 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2538,6 +2538,30 @@ check_reparse_point_target (HANDLE h, bool remote,
PREPARSE_DATA_BUFFER rp,
if (check_reparse_point_string (psymbuf))
return PATH_SYMLINK | PATH_REP;
}
+ else if (!remote && rp->ReparseTag == IO_REPARSE_TAG_APPEXECLINK)
+{
+ /* App execution aliases are commonly used by Windows Store apps. */
+ WCHAR *buf = (WCHAR *)(rp->GenericReparseBuffer.DataBuffer + 4);
+ DWORD size = rp->ReparseDataLength / sizeof(WCHAR), n;
+
+ /*
+ It seems that app execution aliases have a payload of four
+NUL-separated wide string: package id, entry point, executable
+and application type. We're interested in the executable. */
+ for (int i = 0; i < 3 && size > 0; i++)
+{
+ n = wcsnlen (buf, size - 1);
+ if (i == 2 && n > 0 && n < size)
+ {
+ RtlInitCountedUnicodeString (psymbuf, buf, n * sizeof(WCHAR));
+ return PATH_SYMLINK | PATH_REP;
+ }
+ if (i == 2)
+ break;
+ buf += n + 1;
+ size -= n + 1;
+ }
+}
else if (rp->ReparseTag == IO_REPARSE_TAG_LX_SYMLINK)
{
/* WSL symlink. Problem: We have to convert the path to UTF-16 for
--
2.30.2
Re: symbolic links to /cygdrive/X/xxx with capital letter X
On Jun 12 08:06, Arthur Norman via Cygwin wrote: > This running on Windows 10 1909 and cygwin has been updated to the latest > version. The effect was also visible on a freshly installed minimal cygwin > put on an almost fresh Windows 10 VM. > > Cygwin these days seems to have a behaviour that confuses me regarding the > case of a disk name: > > > ln -s "/cygdrive/c/Program Files" pf1 > > ln -s "/cygdrive/C/Program Files" pf2 > > ls -l pf* > lrwxrwxrwx 1 acn1 None 25 Jun 12 07:37 pf1 -> /cygdrive/c/Program Files > lrwxrwxrwx 1 acn1 None 20 Jun 12 07:37 pf2 -> /mnt/C/Program Files > > cygpath -ma ./pf1 > C:/cygwin64/home/acn1/pf1 > > You see from the above that when I use cygpath to convert from a cygwin name > the drive letter C: is returned in upper case. When that ends up after > "/cygdrive" the path behaves as I expect almost everywhere by is treated > specially for symbolic links. This seems to be a relatively new behaviour > and it bit me! > > [Use-case: I wanted to convert cygwin paths to be "very absolute" so that eg If you want "very absolute" paths, use something like ln -s /proc/cygdrive/c/... /proc/cygdrive always exists, even if you change the cygdrive prefix. It's a virtual symlink to the actual cygdrive prefix. Corinna -- Corinna Vinschen Cygwin Maintainer -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: symbolic links to /cygdrive/X/xxx with capital letter X
On Sat, Jun 13, 2020 at 1:50 PM Andrey Repin wrote: > The cygdrive prefix is resolved, if no other mount points match. > Since you have /mnt/C mount point, it is resolved first. I wish it would have resolved it to the cygdrive prefix, because then it would have worked (and would have been /cygdrive/C/Windows). Maybe cygwin is getting confused by the WLS ubuntu install I have? It puts its mounts under /mnt, but cygwin has always used the /cygdrive path. ..wayne.. -- 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: symbolic links to /cygdrive/X/xxx with capital letter X
Greetings, Wayne Davison! > On Fri, Jun 12, 2020 at 4:05 AM Andrey Repin wrote: >> And you've got exactly what you asked for. > I think you missed the important part of the email. Distilled down, > this is wrong: > $ ln -s /cygdrive/C/Windows foo > $ readlink foo > /mnt/C/Windows The cygdrive prefix is resolved, if no other mount points match. Since you have /mnt/C mount point, it is resolved first. > The symlink's value changed to a path that doesn't exist on a typical > install and is now broken. The original /cygdrive/C/Windows path works > fine as long as you have it mounted to ignore case. Perhaps the > rewrite (if it is even required) should change it into > /cygdrive/c/Windows? You can resolve it to `cygpath --proc-cygdrive`, which is more useful, if you want a portable solution. -- With best regards, Andrey Repin Saturday, June 13, 2020 23:44:47 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: symbolic links to /cygdrive/X/xxx with capital letter X
On Fri, Jun 12, 2020 at 4:05 AM Andrey Repin wrote: > And you've got exactly what you asked for. I think you missed the important part of the email. Distilled down, this is wrong: $ ln -s /cygdrive/C/Windows foo $ readlink foo /mnt/C/Windows The symlink's value changed to a path that doesn't exist on a typical install and is now broken. The original /cygdrive/C/Windows path works fine as long as you have it mounted to ignore case. Perhaps the rewrite (if it is even required) should change it into /cygdrive/c/Windows? ..wayne.. -- 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: symbolic links to /cygdrive/X/xxx with capital letter X
Greetings, Arthur Norman! > This running on Windows 10 1909 and cygwin has been updated to the latest > version. The effect was also visible on a freshly installed minimal cygwin > put on an almost fresh Windows 10 VM. > Cygwin these days seems to have a behaviour that confuses me regarding the > case of a disk name: >> ln -s "/cygdrive/c/Program Files" pf1 >> ln -s "/cygdrive/C/Program Files" pf2 >> ls -l pf* > lrwxrwxrwx 1 acn1 None 25 Jun 12 07:37 pf1 -> /cygdrive/c/Program Files > lrwxrwxrwx 1 acn1 None 20 Jun 12 07:37 pf2 -> /mnt/C/Program Files >> cygpath -ma ./pf1 > C:/cygwin64/home/acn1/pf1 > You see from the above that when I use cygpath to convert from a cygwin > name the drive letter C: is returned in upper case. When that ends up > after "/cygdrive" the path behaves as I expect almost everywhere by is > treated specially for symbolic links. This seems to be a relatively new > behaviour and it bit me! > [Use-case: I wanted to convert cygwin paths to be "very absolute" so that > eg my home directory is not rendered as /home/acn1 but as > /cygdrive/c/cygwin64/home/acn1, cygpath is not meant to replace realpath/readlink. And you've got exactly what you asked for. -m returns Windows path with forward slashes. -a returns absolute path. > so I had a few lines of shell script to > achieve that. I was building a package and I build both a cygwin32 and a > cygwin64 version, so the "very absolute" paths are portable between the > two worlds, both of which were important when I first set this up. Things > recently broke and on investigation it was because somewhere deep in > build scripts links to /mnt/C/... had been set up and were not usable. I > can of course work round the issue but being confident I have spotted all > cases causes me work!] readlink -e ./pf1 man readlink -- With best regards, Andrey Repin Friday, June 12, 2020 14:01:51 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
symbolic links to /cygdrive/X/xxx with capital letter X
This running on Windows 10 1909 and cygwin has been updated to the latest version. The effect was also visible on a freshly installed minimal cygwin put on an almost fresh Windows 10 VM. Cygwin these days seems to have a behaviour that confuses me regarding the case of a disk name: ln -s "/cygdrive/c/Program Files" pf1 ln -s "/cygdrive/C/Program Files" pf2 ls -l pf* lrwxrwxrwx 1 acn1 None 25 Jun 12 07:37 pf1 -> /cygdrive/c/Program Files lrwxrwxrwx 1 acn1 None 20 Jun 12 07:37 pf2 -> /mnt/C/Program Files cygpath -ma ./pf1 C:/cygwin64/home/acn1/pf1 You see from the above that when I use cygpath to convert from a cygwin name the drive letter C: is returned in upper case. When that ends up after "/cygdrive" the path behaves as I expect almost everywhere by is treated specially for symbolic links. This seems to be a relatively new behaviour and it bit me! [Use-case: I wanted to convert cygwin paths to be "very absolute" so that eg my home directory is not rendered as /home/acn1 but as /cygdrive/c/cygwin64/home/acn1, so I had a few lines of shell script to achieve that. I was building a package and I build both a cygwin32 and a cygwin64 version, so the "very absolute" paths are portable between the two worlds, both of which were important when I first set this up. Things recently broke and on investigation it was because somewhere deep in build scripts links to /mnt/C/... had been set up and were not usable. I can of course work round the issue but being confident I have spotted all cases causes me work!] Arthur -- 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
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 signature.asc Description: PGP signature -- 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
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. -- 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
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 signature.asc Description: PGP signature -- 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
Greetings, Brian Inglis! > On 2020-03-28 05:59, Andrey Repin wrote: >> Greetings, Brian Inglis! >> Thanks! This should already be fixed in the latest developer snapshot after I was finally able to install WSL myself. See my reply to Thomas in https://sourceware.org/pipermail/cygwin/2020-March/244211.html All the effects are a result of not opening the reparse point as reparse point, as weird as it sounds at first :) >> >>> Would you consider that test program a reasonable base for something I have >>> wished for a while: a program that would classify a file name as a (regular) >>> hard link, a Windows directory or file link, a junction, a Windows >>> shortcut, a >>> Cygwin symlink, a Unix/WSL symlink, a URL link, and/or tell me where it >>> links to >>> etc. Thinking of hacking that plus maybe bits of file, cygpath, >>> readshortcut, >>> readlink, lsattr together to display otherwise awkward to access attributes >>> and >>> properties. >> >> I'd like to see it as part of "file -h" functionality. > Both file and grep are getting worse at distinguishing UTF-8 from binary data, > so I don't want to get into fiddling with that recognizer/interpreter, given > that it can not get or use that information as is, just enough of file to > decide > on or verify a file type; I did mean that. Something like "Windows symbolic link - file" or "Windows symbolic link - unknown type" would be enough to start the investigation into the right direction. -- With best regards, Andrey Repin Sunday, March 29, 2020 14:50:51 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
On 2020-03-28 05:59, Andrey Repin wrote: > Greetings, Brian Inglis! > >>> >>> Thanks! This should already be fixed in the latest developer snapshot >>> after I was finally able to install WSL myself. See my reply to Thomas >>> in https://sourceware.org/pipermail/cygwin/2020-March/244211.html >>> >>> All the effects are a result of not opening the reparse point as reparse >>> point, as weird as it sounds at first :) > >> Would you consider that test program a reasonable base for something I have >> wished for a while: a program that would classify a file name as a (regular) >> hard link, a Windows directory or file link, a junction, a Windows shortcut, >> a >> Cygwin symlink, a Unix/WSL symlink, a URL link, and/or tell me where it >> links to >> etc. Thinking of hacking that plus maybe bits of file, cygpath, readshortcut, >> readlink, lsattr together to display otherwise awkward to access attributes >> and >> properties. > > I'd like to see it as part of "file -h" functionality. Both file and grep are getting worse at distinguishing UTF-8 from binary data, so I don't want to get into fiddling with that recognizer/interpreter, given that it can not get or use that information as is, just enough of file to decide on or verify a file type; for ls: link classification is outside its remit; and swan (SWiss Army kNife) is too vague and wide for my taste: a sharper tool and a more focussed name depending on eventual function like lslink. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
Greetings, Brian Inglis! >> >> Thanks! This should already be fixed in the latest developer snapshot >> after I was finally able to install WSL myself. See my reply to Thomas >> in https://sourceware.org/pipermail/cygwin/2020-March/244211.html >> >> All the effects are a result of not opening the reparse point as reparse >> point, as weird as it sounds at first :) > Would you consider that test program a reasonable base for something I have > wished for a while: a program that would classify a file name as a (regular) > hard link, a Windows directory or file link, a junction, a Windows shortcut, a > Cygwin symlink, a Unix/WSL symlink, a URL link, and/or tell me where it links > to > etc. Thinking of hacking that plus maybe bits of file, cygpath, readshortcut, > readlink, lsattr together to display otherwise awkward to access attributes > and > properties. I'd like to see it as part of "file -h" functionality. -- With best regards, Andrey Repin Saturday, March 28, 2020 14:52:04 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
Am 28.03.2020 um 11:31 schrieb Henry S. Thompson via Cygwin: Brian Inglis writes: ... wished for a while: a program that would classify a file name as a (regular) hard link, a Windows directory or file link, a junction, a Windows shortcut, a Cygwin symlink, a Unix/WSL symlink, a URL link, and/or tell me where it links to etc. Thinking of hacking that plus maybe bits of file, cygpath, readshortcut, readlink, lsattr together to display otherwise awkward to access attributes and properties. Oh, yes please! You could call it 'swan', for Swiss Army Knife :-). Or maybe simply an additional option for `ls -l`? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
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: h...@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. -- 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
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 source from my vault > of old test apps to check on reparse point content. Please compile with > gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll > It takes a single native NT path as parameter, kind of like this: > ./rd-reparse '\??\C:\cygwin64\home\corinna\link' They should be WSL or Windows mklink (soft) links, and the reason why mklink was allowed unelevated in Windows 10 with Developer mode. In an *elevated* shell: $ ls -dln u -rw-r- 1 4294967295 4294967295 0 Nov 9 06:09 u >>>^ >>> This is unknown user, unknown group, which means, the Windows >>> function LookupAccountSid() probably returned a domain name which >>> is unknown (neither account domain, nor primary, nor trusted domain). >>> >>> An strace of `ls -l u' may be helpful... >> >> Attached with startup environment, locale, and message setup cut (reduced by >> 100KB), and rest sanitized as below. Could DM/PM original on request. > > Thanks! This should already be fixed in the latest developer snapshot > after I was finally able to install WSL myself. See my reply to Thomas > in https://sourceware.org/pipermail/cygwin/2020-March/244211.html > > All the effects are a result of not opening the reparse point as reparse > point, as weird as it sounds at first :) Would you consider that test program a reasonable base for something I have wished for a while: a program that would classify a file name as a (regular) hard link, a Windows directory or file link, a junction, a Windows shortcut, a Cygwin symlink, a Unix/WSL symlink, a URL link, and/or tell me where it links to etc. Thinking of hacking that plus maybe bits of file, cygpath, readshortcut, readlink, lsattr together to display otherwise awkward to access attributes and properties. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
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 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 signature.asc Description: PGP signature -- 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
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 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. --- Process 12772 created --- Process 12772 loaded C:\Windows\System32\ntdll.dll at 7ff9e912 --- Process 12772 loaded C:\Windows\System32\kernel32.dll at 7ff9e732 --- Process 12772 loaded C:\Windows\System32\KernelBase.dll at 7ff9e6d3 --- Process 12772 thread 5544 created --- Process 12772 thread 7184 created --- Process 12772 loaded C:\...\cygwin64\bin\cygwin1.dll at 00018004 --- Process 12772 loaded C:\...\cygwin64\bin\cygintl-8.dll at 0003c49c --- Process 12772 thread 15324 created --- Process 12772 loaded C:\...\cygwin64\bin\cygiconv-2.dll at 0003d72e 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 7ff9e78e --- Process 12772 loaded C:\Windows\System32\msvcrt.dll at 7ff9e86d --- Process 12772 loaded C:\Windows\System32\sechost.dll at 7ff9e8a4 --- Process 12772 loaded C:\Windows\System32\rpcrt4.dll at 7ff9e8fc --- Process 12772 loaded C:\Windows\System32\cryptbase.dll at 7ff9e59c --- Process 12772 loaded C:\Windows\System32\bcryptprimitives.dll at 7ff9e626 ... 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 (0x80010, 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, 0xB700) (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 00C3 41 84628 [main] ls 25955 stat_worker: (\??\C:\Users\$USER\u, 0x8000986E0, 0x18034C1E0), file_attributes 32 44 84672
Re: WSL symbolic links
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: 0xa01d ReparseDataLength: 8 Reserved: 0 02 00 00 00 66 69 6c 65 rd-reparse '\??\C:\tmp\link-abs' ; echo ReparseTag: 0xa01d 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: 0xa01d ReparseDataLength: 9 Reserved: 0 02 00 00 00 66 c3 b6 c3 b6 rd-reparse '\??\C:\tmp\link-foo-abs' ; echo ReparseTag: 0xa01d ReparseDataLength: 20 Reserved: 0 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66 c3 b6 c3 b6 [...] I debugged this now and I found that practically all problems, including the inability to delete the symlink, are a result of not being able to open the reparse point correctly as reparse point within Cygwin. So as not to destroy something important, Cygwin only opens reparse points as reparse points if it recognizes the reparse point type. Consequentially, all immediate problems go away, as soon as Cygwin recognizes and handles the symlink :) So I created a patch and pushed it. The latest developer snapshot from https://cygwin.com/snapshots/ contains this patch. Works, great, thank you! Thanks for testing! Funny sidenote: Assuming you create symlinks pointing to files with non-UTF-8 chars, e. g., umlauts in ISO-8859-1, then the symlink converts *all* these chars to the Unicode REPLACEMENT CHARACTER 0xfffd. I assume this will also happen if you try to create the file with these chars in the first place, so it's not much of a problem. As Windows filenames are character strings as opposed to Linux filenames which are byte strings, some strange behaviour is unavoidable. I see: $ wsl ls -l link_LW lrwxrwxrwx 1 towo towo 19 Mar 27 12:11 link_LW -> file_L_ $ ls -l link_LW lrwxrwxrwx 1 towo Kein 11 27. Mrz 13:11 link_LW -> file_L_ which looks OK for me. Not sure I expressed myself correctly there. What I was trying to say is, the symlink created by WSL already contains the 0xfffd replacement char, in UTF-8 \xef \xbf \xbd. So the info is already lost inside the symlink. I couldn't create a non-UTF8 file name in WSL on the command line; even running LC_ALL=de_DE mintty and running WSL LC_ALL=de_DE bash, keyboard input would still appear as UTF-8 when displayed with od, which is weird. Anyway, this can be tricked using touch from a script file of course. In that case, indeed WSL flattens all invalid characters to � already for the filename. However, all symbolic link cases work for me. I can point links to file_L_ and file_LW_ and access the respective files correctly via the links from both WSL and cygwin now. Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
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: 0xa01d > > > ReparseDataLength: 8 > > > Reserved: 0 > > > 02 00 00 00 66 69 6c 65 > > > > rd-reparse '\??\C:\tmp\link-abs' ; echo > > > ReparseTag: 0xa01d > > > 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: 0xa01d > > > ReparseDataLength: 9 > > > Reserved: 0 > > > 02 00 00 00 66 c3 b6 c3 b6 > > > > rd-reparse '\??\C:\tmp\link-foo-abs' ; echo > > > ReparseTag: 0xa01d > > > 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 signature.asc Description: PGP signature -- 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
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, 0xa00c. 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: 0xa01d ReparseDataLength: 8 Reserved: 0 02 00 00 00 66 69 6c 65 rd-reparse '\??\C:\tmp\link-abs' ; echo ReparseTag: 0xa01d 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: 0xa01d ReparseDataLength: 9 Reserved: 0 02 00 00 00 66 c3 b6 c3 b6 rd-reparse '\??\C:\tmp\link-foo-abs' ; echo ReparseTag: 0xa01d 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: C034 Yeah, that's expected. The test app only handles filename with ASCII chars. It's questionable if supporting this new symlink type makes sense, but taking a closer look doesn't hurt, I guess. Well, at least they should be deletable, I think. I debugged this now and I found that practically all problems, including the inability to delete the symlink, are a result of not being able to open the reparse point correctly as reparse point within Cygwin. So as not to destroy something important, Cygwin only opens reparse points as reparse points if it recognizes the reparse point type. Consequentially, all immediate problems go away, as soon as Cygwin recognizes and handles the symlink :) So I created a patch and pushed it. The latest developer snapshot from https://cygwin.com/snapshots/ contains this patch. Works, great, thank you! Funny sidenote: Assuming you create symlinks pointing to files with non-UTF-8 chars, e. g., umlauts in ISO-8859-1, then the symlink converts *all* these chars to the Unicode REPLACEMENT CHARACTER 0xfffd. I assume this will also happen if you try to create the file with these chars in the first place, so it's not much of a problem. As Windows filenames are character strings as opposed to Linux filenames which are byte strings, some strange behaviour is unavoidable. I see: $ wsl ls -l link_LW lrwxrwxrwx 1 towo towo 19 Mar 27 12:11 link_LW -> file_L_ $ ls -l link_LW lrwxrwxrwx 1 towo Kein 11 27. Mrz 13:11 link_LW -> file_L_ which looks OK for me. Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
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, 0xa00c. 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: 0xa01d > ReparseDataLength: 8 > Reserved: 0 > 02 00 00 00 66 69 6c 65 > > rd-reparse '\??\C:\tmp\link-abs' ; echo > ReparseTag: 0xa01d > 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: 0xa01d > ReparseDataLength: 9 > Reserved: 0 > 02 00 00 00 66 c3 b6 c3 b6 > > rd-reparse '\??\C:\tmp\link-foo-abs' ; echo > ReparseTag: 0xa01d > 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: C034 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 signature.asc Description: PGP signature -- 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
Thomas Wolff writes: >> - Last but not least, could you please create a symlink pointing to a >>target with a non-ASCII char, e. g., some german umlaut? > Not sure what kind of remote you'd like to see. I have a 'net use' > (cifs/smbfs) mounted drive but couldn't mount it in WSL. Otherwise: That's exactly why WSL is so nearly useless to me and why Cygwin continues to hold its place. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
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 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: 0xa01d ^^ This is a reparse point tag different from the normal Windows symlink reparse point tag, 0xa00c. 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: 0xa01d ReparseDataLength: 8 Reserved: 0 02 00 00 00 66 69 6c 65 > rd-reparse '\??\C:\tmp\link-abs' ; echo ReparseTag: 0xa01d 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: 0xa01d ReparseDataLength: 9 Reserved: 0 02 00 00 00 66 c3 b6 c3 b6 > rd-reparse '\??\C:\tmp\link-foo-abs' ; echo ReparseTag: 0xa01d 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: C034 It's questionable if supporting this new symlink type makes sense, but taking a closer look doesn't hurt, I guess. Well, at least they should be deletable, I think. Thomas Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
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 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 signature.asc Description: PGP signature -- 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 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 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: 0xa01d ^^ This is a reparse point tag different from the normal Windows symlink reparse point tag, 0xa00c. 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 signature.asc Description: PGP signature -- 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
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 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: 0xa01d ReparseDataLength: 5 Reserved: 0 02 00 00 00 75 -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
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 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: 0xa01d ReparseDataLength: 8 Reserved: 0 02 00 00 00 66 69 6c 65 Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
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 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
#include
#include
#include
#include
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 (, argv[1]);
InitializeObjectAttributes(, , OBJ_CASE_INSENSITIVE, NULL, 0);
status = NtOpenFile (, FILE_READ_EA | FILE_READ_ATTRIBUTES | SYNCHRONIZE,
, ,
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, ,
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;
}
signature.asc
Description: PGP signature
--
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
WSL symbolic links
A symbolic link created with WSL is neither interpreted in cygwin nor can it be deleted: > touch file > wsl ln -s file link > wsl ls -l link lrwxrwxrwx 1 towo towo 1 Mar 26 08:56 link -> file > ls -l link -rw-r- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link > rm -f link /bin/rm: cannot remove 'link': Permission denied (even as admin) > cmd /c del link works. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Copying of symbolic links not working as expected
On 21.04.2019 14:45, Matt D. wrote: > > I had the same problem while trying to tar and untar: > > tar: aosp/source/system/vold/.git/shallow: Cannot create symlink to > ‘../../../.repo/projects/system/vold.git/shallow’: No such file or directory My current workaround for *this* particular problem is to catch the "Cannot create symlink" message and attempt to re-run tar multiple times until the message is no longer outputted or the script runs out of attempts. This works OK, unless the symlink graph is maliciously gnarly. I doubt that this will be fixed anytime soon, it's a property of the NTFS, and you should have known what you were signing on for when you enabled winsymlinks:nativestrict (i'm assuming that you did; otherwise you shouldn't have been getting these errors). signature.asc Description: OpenPGP digital signature
Re: Copying of symbolic links not working as expected
On 4/21/2019 7:45 AM, Matt D. wrote: Note that this creates a chicken-and-the-egg problem when copying paths which contain symbolic links which will be but are not yet valid at the time of copying. For example, copying a very large and complex tree with many lots of links will result in a broken copy. I'm trying to copy a directory tree right now and it's a major headache. Dear Matt - My reading of the cp man page suggests that the -d flag addresses this issue for cp. Now tar has these flags available: -h (--dereference) to follow sym links, and --hard-dereference to follow hard links This suggests that tar does not normally follow links. So I am less certain what is happening there. Another program you might consider is rsync. While I normally think of it as being for efficient cross-network copying, it works within a system as well. It will pay to read through about its flags before trying to use it for this purpose. It is true that, compared with Linux, Cygwin symlinks are slightly funky in that they are true files in the Windows file system, but with a specific format that Cygwin recognizes as special but Windows does not. But that should not generally be noticeable when using generic Cygwin versions of programs such as these. Regards - Eliot Moss -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Copying of symbolic links not working as expected
Note that this creates a chicken-and-the-egg problem when copying paths which contain symbolic links which will be but are not yet valid at the time of copying. For example, copying a very large and complex tree with many lots of links will result in a broken copy. I'm trying to copy a directory tree right now and it's a major headache. For example: $ cp -ra /c/data/repositories/ /c/development/repositories/ cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifest.xml': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests/.git/config': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests/.git/description': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests/.git/hooks': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests/.git/info': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests/.git/logs': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests/.git/objects': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests/.git/packed-refs': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests/.git/refs': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests/.git/rr-cache': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests/.git/shallow': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests/.git/svn': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests.git/hooks/commit-msg': No such file or directory cp: cannot create symbolic link '/c/development/repositories/repositories/aosp/source/.repo/manifests.git/hooks/pre-auto-gc': No such file or directory ... And so on. I had the same problem while trying to tar and untar: tar: aosp/source/system/vold/.git/shallow: Cannot create symlink to ‘../../../.repo/projects/system/vold.git/shallow’: No such file or directory tar: aosp/source/system/vold/.git/packed-refs: Cannot create symlink to ‘../../../.repo/projects/system/vold.git/packed-refs’: No such file or directory tar: aosp/source/system/netd/.git/shallow: Cannot create symlink to ‘../../../.repo/projects/system/netd.git/shallow’: No such file or directory tar: aosp/source/system/netd/.git/packed-refs: Cannot create symlink to ‘../../../.repo/projects/system/netd.git/packed-refs’: No such file or directory tar: aosp/source/system/media/.git/shallow: Cannot create symlink to ‘../../../.repo/projects/system/media.git/shallow’: No such file or directory tar: aosp/source/system/media/.git/packed-refs: Cannot create symlink to ‘../../../.repo/projects/system/media.git/packed-refs’: No such file or directory tar: aosp/source/system/extras/.git/shallow: Cannot create symlink to ‘../../../.repo/projects/system/extras.git/shallow’: No such file or directory tar: aosp/source/system/extras/.git/packed-refs: Cannot create symlink to ‘../../../.repo/projects/system/extras.git/packed-refs’: No such file or directory tar: aosp/source/system/core/.git/shallow: Cannot create symlink to ‘../../../.repo/projects/system/core.git/shallow’: No such file or directory tar: aosp/source/system/core/.git/packed-refs: Cannot create symlink to ‘../../../.repo/projects/system/core.git/packed-refs’: No such file or directory tar: aosp/source/system/bluetooth/.git/shallow: Cannot create symlink to ‘../../../.repo/projects/system/bluetooth.git/shallow’: No such file or directory tar: aosp/source/sdk/.git/shallow: Cannot create symlink to ‘../../.repo/projects/sdk.git/shallow’: No such file or directory tar: aosp/source/sdk/.git/packed-refs: Cannot create symlink to ‘../../.repo/projects/sdk.git/packed-refs’: No such file or directory tar: aosp/source/prebuilt/.git/shallow: Cannot create symlink to ‘../../.repo/projects/prebuilt.git/shallow’: No such file or directory tar: aosp/source/prebuilt/.git/packed-refs: Cannot create symlink to ‘../../.repo/projects/prebuilt.git/packed-refs’: No such file or directory tar: aosp/source/packages/wallpapers/PhaseBeam/.git/shallow: Cannot create symlink to ‘../../../../.repo/projects/packages/wallpapers/PhaseBeam.git/shallow’: No such file or directory tar: aosp/source/packages/wallpapers/PhaseBeam/.git/packed-refs
Copying of symbolic links not working as expected
I'm experiencing a discrepancy between Linux cp and Cygwin cp when copying native symbolic links: Test/ FolderA/ 123/ 456/ -> 123/ On Linux I can: > cp -r FolderA/ FolderB/ > ls -l FolderB/ total 0 drwxrwxr-x. 2 account group 45 Apr 21 05:47 123 lrwxrwxrwx. 1 account group 4 Apr 21 05:47 456 -> 123/ Entire folder copied with relative symblic link paths preserved. *** (starting from the original state -- rm -rf FolderB/) *** > mkdir FolderB/ > cp -r FolderA/456 FolderB/ > ls -l FolderB/ total 0 lrwxrwxrwx. 1 account group 4 Apr 21 05:47 456 -> 123/ Note that "456 -> 123/" in "FolderB/" is a BROKEN link. This is DESIRABLE as it preserves my curated symbolic links with their relative paths. On Cygwin: > cp -r FolderA/ FolderB/ ... Works as expected But: > cp -r FolderA/456 FolderB/ ERRORS: cp: cannot create symbolic link 'FolderB/456': No such file or directory I know that there is no file or directory there. I'm trying to copy one to this location. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can't create symbolic links in child directories
On Mar 31 19:24, Matt D. wrote: > This works: > > > touch a > > ln -s a b > > This no longer works: > > > touch a > > mkdir b > > ln -s a b/c > > Error: > > ln: failed to create symbolic link 'b/c': No such file or directory > > My CYGWIN environment is also configured using "winsymlinks:nativestrict". I'm pretty sure this never worked. Consider what "nativestrict" means. The target has to exist to allow the native symlink being created type-correct. In your example the target doesn't exist: ln -s a b/c means, c points to a. So a is expected in the same directory as c. So looking from the point of the current directory the symlink b/c is supposed to point to the file b/a. Which doesn't exist. Which lets symlinking with nativestrict fail. "winsymlinks:native" will work, albeit creating a Cygwin symlink then. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Can't create symbolic links in child directories
This works: > touch a > ln -s a b This no longer works: > touch a > mkdir b > ln -s a b/c Error: ln: failed to create symbolic link 'b/c': No such file or directory My CYGWIN environment is also configured using "winsymlinks:nativestrict". I am running the following version (updated today): CYGWIN_NT-10.0-WOW WORKSTATION 3.0.5(0.338/5/3) 2019-03-31 11:22 i686 Cygwin I cannot confirm at which point this bug appeared as I updated from some version prior to 3.0. I am reasonably certain that this has worked before as I use symbolic links often. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
