27;s just a file to `ls` as well:
$ ls -l des.h
-rwxrwx---+ 1 Administrators None 58 Jan 3 12:21 des.h
I just pulled https://openssl.org/source/openssl-1.0.2p.tar.gz and the
shipped include folder is empty, so part of the build process must be to
set up the include links. When you copy thos
I assume you meant cygcheck
<https://cygwin.com/cygwin-ug-net/cygcheck.html>, not symcheck ?
( i've been "into" symbolic links in cygwin today so the title caught my
eye )
what do you have for the CYGWIN environment variable, I've been using
winsymlinks
On Tue, 05 Mar 2024 20:48:38 +0900 (JST)
Masamichi Hosoda wrote:
> libfontconfig-devel-2.15.0-1 links wrong DLL (i.e. libfontconfig-1.dll)
Thanks for the report. I'll fix that and release version 2.15.0-2.
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.
Hi
If I understand correctly,
libfontconfig-devel-2.15.0-1 links wrong DLL (i.e. libfontconfig-1.dll)
instead of correct DLL (i.e. cygfontconfig-1.dll).
Since the wrong DLL does not exist,
the executable file using libfontconfig-devel-2.15.0-1 cannot be executed.
```
$ cat foo.c
#include
int
>> Cygwin never creates Windows Directory or Filesystem Junction reparse points,
>> and by default it uses its own version of Unix path symlink files, preceded
>> by
>> a flag ("magic cookie") value, and with system attribute, to allow
>> compatibility with FAT file system limitations, or else N
be used to
differ between soft links and Windows junctions?
Distinguishing between types of Windows reparse points is not a POSIX or
emulation function, so not of interest to Cygwin developers.
I thought about it when support was added, but then realized there was no nice
place to add it within
t; Does Cygwin have a command line tool (Scriptable!) which can
> > > > > be used to
> > > > > differ between soft links and Windows junctions?
> >
> > Distinguishing between types of Windows reparse points is not a POSIX or
> > emulation function, so n
Am 16.11.2023 um 21:30 schrieb Brian Inglis via Cygwin:
On 2023-11-16 11:55, matthew patton via Cygwin wrote:
On Thursday, November 16, 2023 at 03:50:24 AM EST, Andrey Repin wrote:
Does Cygwin have a command line tool (Scriptable!) which can be
used to
differ between soft links and Windows
> On Wed, Nov 1, 2023 at 10:14 AM Martin Wege wrote:
> >
> > Good morning!
> >
> > Does Cygwin have a command line tool (Scriptable!) which can be used
> > to differ between soft links and Windows junctions?
> >
> > Thanks,
> > Martin
Cygwin it
On 2023-11-16 11:55, matthew patton via Cygwin wrote:
On Thursday, November 16, 2023 at 03:50:24 AM EST, Andrey Repin wrote:
Does Cygwin have a command line tool (Scriptable!) which can be used to
differ between soft links and Windows junctions?
Distinguishing between types of Windows reparse
sed
> to differ between soft links and Windows junctions?
It would be easier to help you, if you specify the purpose of your request.
I.e. what you want to achieve with such tool.
--
With best regards,
Andrey Repin
Thursday, November 16, 2023 11:46:09
Sorry for my terrible english...
--
P
Greetings, Martin Wege!
> Does Cygwin have a command line tool (Scriptable!) which can be used
> to differ between soft links and Windows junctions?
It would be easier to help you, if you specify the purpose of your request.
I.e. what you want to achieve with such tool.
--
With best r
?
On Wed, Nov 1, 2023 at 10:14 AM Martin Wege wrote:
>
> Good morning!
>
> Does Cygwin have a command line tool (Scriptable!) which can be used
> to differ between soft links and Windows junctions?
>
> Thanks,
> Martin
--
Problem reports: https://cygw
Greetings, Jim Garrison via Cygwin!
> On 07/21/23 14:52, Brian Inglis wrote:
>> On 2023-07-21 14:59, Jim Garrison via Cygwin wrote:
>>> Git comes with over 100 executables, mostly in /usr/libexec/git-core,
>>> that all appear to be *hard* links to /bin/git, in both
Good morning!
Does Cygwin have a command line tool (Scriptable!) which can be used
to differ between soft links and Windows junctions?
Thanks,
Martin
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com
executables, mostly in /usr/libexec/git-core,
that all appear to be *hard* links to /bin/git, in both Cygwin and
Windows. The Windows fsutil command shows they're all hard linked:
[snip]
I'm curious to know if there's a specific reason for this implementation
tha
* links to /bin/git, in both Cygwin and
Windows. The Windows fsutil command shows they're all hard linked:
[snip]
I'm curious to know if there's a specific reason for this implementation
that would make it the choice over symbolic links.
For the same reason you are complaining ab
On Fri, 21 Jul 2023 at 22:54, Jim Garrison via Cygwin wrote:
>
> On 07/21/23 14:52, Brian Inglis wrote:
> > On 2023-07-21 14:59, Jim Garrison via Cygwin wrote:
> >> Git comes with over 100 executables, mostly in /usr/libexec/git-core,
> >> that all appear to be *ha
On 7/21/23 17:54, Jim Garrison via Cygwin wrote:
On 07/21/23 14:52, Brian Inglis wrote:
On 2023-07-21 14:59, Jim Garrison via Cygwin wrote:
Git comes with over 100 executables, mostly in /usr/libexec/git-core,
that all appear to be *hard* links to /bin/git, in both Cygwin and
Windows. The
On 07/21/23 14:52, Brian Inglis wrote:
On 2023-07-21 14:59, Jim Garrison via Cygwin wrote:
Git comes with over 100 executables, mostly in /usr/libexec/git-core,
that all appear to be *hard* links to /bin/git, in both Cygwin and
Windows. The Windows fsutil command shows they're all hard l
On 2023-07-21 14:59, Jim Garrison via Cygwin wrote:
Git comes with over 100 executables, mostly in /usr/libexec/git-core,
that all appear to be *hard* links to /bin/git, in both Cygwin and
Windows. The Windows fsutil command shows they're all hard linked:
C:\Users\jim>fsutil hardl
Git comes with over 100 executables, mostly in /usr/libexec/git-core,
that all appear to be *hard* links to /bin/git, in both Cygwin and
Windows. The Windows fsutil command shows they're all hard linked:
C:\Users\jim>fsutil hardlink list "c:\cygwin64\bin\git.exe"
\cy
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
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
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
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
>
> -
> 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.
> > >
> > >
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
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&#
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
ipt to solve the issue (see attachment).
> Also in attachment a powershell startup wrapper for /usr/local/bin/
find -L / -xdev -type l -execdir fixmylinks.ps1 OldPathFragment
New\\PathFragment '{}' +
In all broken links, script will look for "OldPathFragment", and if replacing
t
sh
lrwxrwxrwx 1 anrdaemon None 14 Nov 18 2021 ./usr/lib/tk8.6/tkConfig.sh ->
../tkConfig.sh
Is this… normal ?
The first four are consequences of the fact that /bin is the same as /usr/bin
and /lib is the same as /usr/lib. The links in question were actually installed
in /usr/bin or /usr/l
Greetings, All!
# LC_ALL=C.UTF-8 find -L / -xdev -type l -exec ls -ld --color '{}' +
lrwxrwxrwx 1 anrdaemon None 28 Dec 26 2021 ./bin/rcs2log ->
../share/cvs/contrib/rcs2log
lrwxrwxrwx 1 anrdaemon None 15 Nov 10 2021 ./lib/tcl8.6/tclConfig.sh ->
../tclConfig.sh
lrwxrwxrwx 1 anrdaemon None 17 F
en 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
&g
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
re 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:/cyg
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
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
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 cooper
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 l
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
--
Pr
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'
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.c
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.
Th
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
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 th
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 20
> 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, 20
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 d
> 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
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
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 no
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 threa
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 bar
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 do
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 pat
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 th
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 sym
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 con
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 intende
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
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
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 no
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/25
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
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 Virtual
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,
suppor
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
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-*
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
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
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.
>
&
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 upda
@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 Virtual
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 ha
ld recognize them as symlinks.
So why would ".lnk" files be used in cygwin packages since they don't
work under cygwin, but are 'explorer' links.
What happens if you type 'amstex --help' in a Cygwin shell?
Ken
--
Problem reports: https://cygwin.com/pro
I have about 99 ".lnk" files in my /bin dir.
What are these for?
They appear to be explorer links to various things, to list
some files w/o the .lnk extension:
( /bin/ls -T 0 -x -w 96 |sed -r 's/\.lnk//g' )
Console2 a2ping a5toa4
On Thu, 29 Jul 2021 at 12:31, Adam Dinwoodie wrote:
>
> On Thu, 29 Jul 2021 at 11:27, Roosz, Matthias via Cygwin wrote:
> > most Cygwin webpage links cannot be navigated to, e.g. 'Gold Stars' points
> > to https://cygwin.com/goldstars/, the working link (both in cur
On Thu, 29 Jul 2021 at 11:27, Roosz, Matthias via Cygwin wrote:
> most Cygwin webpage links cannot be navigated to, e.g. 'Gold Stars' points to
> https://cygwin.com/goldstars/, the working link (both in current Chrome and
> Firefox) for me is https://www.cygwin.com/goldsta
Hi,
most Cygwin webpage links cannot be navigated to, e.g. 'Gold Stars' points to
https://cygwin.com/goldstars/, the working link (both in current Chrome and
Firefox) for me is https://www.cygwin.com/goldstars/
Where ever my browser tells me 'Hmm. We're having troub
;/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 absolu
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 /cygdriv
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 p
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 exi
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
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
beh
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
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
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 Wi
r 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 Uni
d 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 hack
ndows 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 t
/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
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. Thinkin
rld? Reparse points? If so,
>>>>> what content do they have? I attached a Q&D source from my vault
>>>>> of old test apps to check on reparse point content. Please compile with
>>>>> gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll
>>>&g
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-re
gt;>> 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 mk
yed 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
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:
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
1 - 100 of 497 matches
Mail list logo
