realpath issue with native[strict] symlinks

realpath issue with native[strict] symlinks

[Orgad Shaneh]

Hi,

When winsymlinks:native/nativestrict is used, realpath doesn't resolve
the full path correctly, when a symlink to the same directory is used.

Example follows. The output is:
/home/user/recurse/test/d1
/home/user/recurse/test2/d1

While it should be /home/user/recurse/d1 for both.

A few observations:
1. When CYGWIN is not set at all, the link is created as a junction.
It works ok in cygwin, but cannot be accessed from cmd (probably
because it is a file junction, and not a directory one). On this case,
realpath works as expected.
2. If I create a junction using mklink /j test3 ., the issue reproduces,
regardless of winsymlinks configuration.

#!/bin/sh

export CYGWIN=winsymlinks:nativestrict
rm -rf recurse
mkdir recurse
cd recurse
mkdir d1
ln -s . test
ln -s $PWD test2
cmd ///c 'mklink /j test3 .'
(cd test/d1 && realpath .)
(cd test2/d1 && realpath .)
(cd test3/d1 && realpath .)

- Orgad

Re: realpath issue with native[strict] symlinks

[Corinna Vinschen]

On Apr 18 10:59, Orgad Shaneh via Cygwin wrote:
> Hi,
> 
> When winsymlinks:native/nativestrict is used, realpath doesn't resolve
> the full path correctly, when a symlink to the same directory is used.
> 
> Example follows. The output is:
> /home/user/recurse/test/d1
> /home/user/recurse/test2/d1
> 
> While it should be /home/user/recurse/d1 for both.

I was going to write:

  Nothing we can do about without re-implementing Cygwin's path handling
  from scratch.  For historical reasons, POSIX paths are evaluated in a
  non-POSIXy manner from right to left.  If the resulting path is an
  existing path, the assumption is that no inner path component is a
  symlink.  That's true as long as Windows didn't support
  symlinks/junctions and Cygwin didn't support them.

But now I'm writing this:

  Probably I have a workaround for this problem.  I added a certain test
  to the function checking the outer path component, so the checks for
  path validity don't stop at the outer path component, just because
  it's a valid Windows path.

I pushed the patch and uploaded new developer snapshots to
https://cygwin.com/snapshots/

Please give them a try.


Thanks,
Corinna

Re: realpath issue with native[strict] symlinks

[Jeremy Drake]

On Fri, 28 May 2021, Jeremy Drake wrote:

> On Thu, 27 May 2021, Jeremy Drake wrote:
>
> > > > Treating mapped/subst drives as though they were not symlinks, without
> > > > messing with intermedate symlinks.
> > >
> > > It was that simple, surprise, surprise...
> >
> > It turns out it wasn't, after all.  This only seems to work at the root of
> > a subst-ed drive.  I just got the following error:
>

There was another report of someone running into an issue with this
change, though not exactly the same situation as mine:
https://github.com/msys2/msys2-runtime/issues/41#issuecomment-854913283

It seems that a mapped network drive is being 'dereferenced', confusing
eclipse trying to find source files from debug info from an arm
cross-compiler.

Unfortunately I have not heard back whether or not my patch helps this
case.

Re: realpath issue with native[strict] symlinks

[Jeremy Drake]

On Thu, 27 May 2021, Jeremy Drake wrote:

> > > Treating mapped/subst drives as though they were not symlinks, without
> > > messing with intermedate symlinks.
> >
> > It was that simple, surprise, surprise...
>
> It turns out it wasn't, after all.  This only seems to work at the root of
> a subst-ed drive.  I just got the following error:

I was thinking about this more, and maybe I'm fixated on the wrong code
(since that code change "broke" it).  Perhaps SUBST drives *should* be
treated as native symlinks, and what needs to change is that native
symlinks should not be dereferenced when launching native programs.  I
assume the symlink-dereferencing there predates the native symlink
support, and was required since native programs wouldn't be able to
traverse a cygwin symlink or .lnk file.

realpath issue with native[strict] symlinks

[Jeremy Drake]

> > Treating mapped/subst drives as though they were not symlinks, without
> > messing with intermedate symlinks.
>
> It was that simple, surprise, surprise...

It turns out it wasn't, after all.  This only seems to work at the root of
a subst-ed drive.  I just got the following error:
error: [Errno 2] No such file or directory:
'C:/msys32/home/Administrator/MINGW-packages/mingw-w64-python-sphinxcontrib-serializinghtml/pkg/mingw-w64-clang-aarch64-python-sphinxcontrib-serializinghtml/clangarm64/lib/python3.8/site-packages/sphinxcontrib/serializinghtml/locales/sphinxcontrib.serializinghtml.pot'

Where T:\ -> C:\msys32\home\Administrator\MINGW-packages and current
directory was under /t/

I was under the impression that that code iterated through path
components, so simply claiming that it wasn't a symlink when it got to the
"symlink" at the root of the drive would suffice, but apparently it's not
so simple.

Re: realpath issue with native[strict] symlinks

[Corinna Vinschen]

On May 18 13:01, Jeremy Drake via Cygwin wrote:
> Sorry ,forgot subject
> 
> On Tue, 18 May 2021, Jeremy Drake wrote:
> 
> > > Sorry, but there's only this or that, not both.  Either we revert the
> > > entire change, including the native shortcut stuff, or we do it
> > > completely and fully, including handling virtual drives as symlinks.
> >
> > I had success with just the following change (of course comments would
> > also need to be updated):
> >
> > diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
> > index 4ebaf4dc6..53534b8b6 100644
> > --- a/winsup/cygwin/path.cc
> > +++ b/winsup/cygwin/path.cc
> > @@ -3670,8 +3670,7 @@ restart:
> >  		   somewhere else, thus, it's a symlink in POSIX speak. */
> >  		if (upath.Length == 14)	/* \??\X:\ */
> >  		  {
> > -		    fileattr &= ~FILE_ATTRIBUTE_DIRECTORY;
> > -		    path_flags |= PATH_SYMLINK;
> > +		    goto file_not_symlink;
> >  		  }
> >  		/* For final paths differing in inner path components return
> >  		   length as negative value.  This informs path_conv::check
> >
> > Treating mapped/subst drives as though they were not symlinks, without
> > messing with intermedate symlinks.

It was that simple, surprise, surprise...

I pushed the change under your name.


Thanks,
Corinna

Re: realpath issue with native[strict] symlinks

[Jeremy Drake]

Sorry ,forgot subject

On Tue, 18 May 2021, Jeremy Drake wrote:

> > Sorry, but there's only this or that, not both.  Either we revert the
> > entire change, including the native shortcut stuff, or we do it
> > completely and fully, including handling virtual drives as symlinks.
>
> I had success with just the following change (of course comments would
> also need to be updated):
>
> diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
> index 4ebaf4dc6..53534b8b6 100644
> --- a/winsup/cygwin/path.cc
> +++ b/winsup/cygwin/path.cc
> @@ -3670,8 +3670,7 @@ restart:
>  		   somewhere else, thus, it's a symlink in POSIX speak. */
>  		if (upath.Length == 14)	/* \??\X:\ */
>  		  {
> -		    fileattr &= ~FILE_ATTRIBUTE_DIRECTORY;
> -		    path_flags |= PATH_SYMLINK;
> +		    goto file_not_symlink;
>  		  }
>  		/* For final paths differing in inner path components return
>  		   length as negative value.  This informs path_conv::check
>
> Treating mapped/subst drives as though they were not symlinks, without
> messing with intermedate symlinks.
>

-- 
Worst Response To A Crisis, 1985:
	From a readers' Q and A column in TV GUIDE: "If we get involved
	in a nuclear war, would the electromagnetic pulses from exploding
	bombs damage my videotapes?"

Re: realpath issue with native[strict] symlinks

[Corinna Vinschen]

On May 14 21:12, Jeremy Drake via Cygwin wrote:
> I apologize for not replying to the message properly, I am not subscribed
> and am copy-pasting from web archive.
> 
> On Sat, May 8, 2021 at 12:20 AM Corinna Vinschen wrote:
> > The changes have a behavioral change, but I think this is for the
> > better: Virtual drives are not treated as drives anymore, but as
> > symlinks.  Given they are just pointers to other drives or directories,
> > tha't much closer to reality.  I. e., in case of my above virtual drive
> > T:, what you'll see in the /cygdrive dir (unless your cygdrive prefix is
> > / only) is this:
> 
> I am concerned about this behavior.  The reason I was using subst to begin
> with was that some build tools encode the full path in their filenames,
> resulting in hitting MAX_PATH-related issues for not horribly long/deep
> paths.  With this change, running a native Windows process (MinGW-w64)
> from a subst drive results in what it sees as the CWD being 'dereferenced'
> as though subst was not used, defeating the path-shortening purpose.

Sorry, but there's only this or that, not both.  Either we revert the
entire change, including the native shortcut stuff, or we do it
completely and fully, including handling virtual drives as symlinks.

The alternative is to rewrite the path handling from scratch, which
is a massive undertaking I simply don't have the time for.

MAX_PATH is not of big concern anymore thiese days.  More recent Windows
10 allows long path names in the ANSI interface as well.  If you're using
dumb tools not being able to cope with such long paths, then use a wrapper
converting the affected paths back to a drive letter.

It might also be helpful to put matching functionality into the cygpath
tool.  Patches are welcome.


Corinna

realpath issue with native[strict] symlinks

[Jeremy Drake]

I apologize for not replying to the message properly, I am not subscribed
and am copy-pasting from web archive.

On Sat, May 8, 2021 at 12:20 AM Corinna Vinschen wrote:
> The changes have a behavioral change, but I think this is for the
> better: Virtual drives are not treated as drives anymore, but as
> symlinks.  Given they are just pointers to other drives or directories,
> tha't much closer to reality.  I. e., in case of my above virtual drive
> T:, what you'll see in the /cygdrive dir (unless your cygdrive prefix is
> / only) is this:

I am concerned about this behavior.  The reason I was using subst to begin
with was that some build tools encode the full path in their filenames,
resulting in hitting MAX_PATH-related issues for not horribly long/deep
paths.  With this change, running a native Windows process (MinGW-w64)
from a subst drive results in what it sees as the CWD being 'dereferenced'
as though subst was not used, defeating the path-shortening purpose.

For instance, using your example mapping:
> $ ls -lG /cygdrive
> total 16
> d---r-x---+ 1 TrustedInstaller  0 Apr 29 21:07 c
> drwxr-xr-x  1 corinna           0 Dec 31  1979 e
> lrwxrwxrwx  1 corinna          32 May  6 20:43 t -> /cygdrive/c/cygwin64/home/corinna/tmp

Prior to these changes would show
$ cd /cygdrive/t && cmd /c cd
T:\

But after these changes would show
$ cd /cygdrive/t && cmd /c cd
C:\cygwin64\home\corinna\tmp

This path could well be long enough to trigger build issues for certain
MINGW-packages.

Sorry to be a nuisance...

Re: realpath issue with native[strict] symlinks

[Corinna Vinschen]

On May 12 10:10, Andrey Repin via Cygwin wrote:
> Greetings, Corinna Vinschen via Cygwin!
> 
> > I reworked the code handling native symlinks to handle virtual drives
> > as well.  It might even be a tiny bit quicker now.
> 
> > The changes have a behavioral change, but I think this is for the
> > better: Virtual drives are not treated as drives anymore, but as
> > symlinks.  Given they are just pointers to other drives or directories,
> > tha't much closer to reality.  I. e., in case of my above virtual drive
> > T:, what you'll see in the /cygdrive dir (unless your cygdrive prefix is
> > / only) is this:
> 
> > $ ls /cygdrive
> > $ ls -lG /mnt
> > total 16
> > d---r-x---+ 1 TrustedInstaller  0 Apr 29 21:07 c
> > drwxr-xr-x  1 corinna           0 Dec 31  1979 e
> > lrwxrwxrwx  1 corinna          32 May  6 20:43 t -> /cygdrive/c/cygwin64/home/corinna/tmp
> 
> > I uploaded new developer snapshots to https://cygwin.com/snapshots/
> > for testing.
> 
> Interesting effect.
> I do have fstab entry
> none / cygdrive noacl,binary,nouser,posix=0 0 0
> And this is what I see with and without changes.
> 
> (3.2.0)
> $ ls -ld /proc/cygdrive/{a..z} 2> /dev/null
> drwxr-x--- 1 anrdaemon None 0 апр 22 23:12 /proc/cygdrive/c
> drwxr-x--- 1 anrdaemon None 0 апр 30 18:05 /proc/cygdrive/d
> drwxr-x--- 1 anrdaemon None 0 апр 22 23:11 /proc/cygdrive/e
> drwxr-x--- 1 anrdaemon None 0 май 11 21:27 /proc/cygdrive/w
> drwxr-x--- 1 anrdaemon None 0 фев 14  2018 /proc/cygdrive/y
> drwxr-x--- 1 anrdaemon None 0 май 12 03:59 /proc/cygdrive/z
> 
> (snapshot)
> $ ls -ld /proc/cygdrive/{a..z} 2> /dev/null
> drwxr-x--- 1 anrdaemon None  0 апр 22 23:12 /proc/cygdrive/c
> drwxr-x--- 1 anrdaemon None  0 апр 30 18:05 /proc/cygdrive/d
> drwxr-x--- 1 anrdaemon None  0 апр 22 23:11 /proc/cygdrive/e
> drwxr-x--- 1 anrdaemon None  0 май 11 21:27 /proc/cygdrive/w
> lrwxrwxrwx 1 anrdaemon None 35 фев 14  2018 /proc/cygdrive/y -> //HOSTING64.DARKDRAGON.LAN/wwwroot/
> lrwxrwxrwx 1 anrdaemon None 35 май 12 03:59 /proc/cygdrive/z -> //DAEMON1.DARKDRAGON.LAN/anrdaemon/

Great, this is the Tip of the Day!

> I think I like these changes.
> Thank you very much.

You're welcome.


Corinna

Re: realpath issue with native[strict] symlinks

[Andrey Repin]

Greetings, Corinna Vinschen via Cygwin!

> I reworked the code handling native symlinks to handle virtual drives
> as well.  It might even be a tiny bit quicker now.

> The changes have a behavioral change, but I think this is for the
> better: Virtual drives are not treated as drives anymore, but as
> symlinks.  Given they are just pointers to other drives or directories,
> tha't much closer to reality.  I. e., in case of my above virtual drive
> T:, what you'll see in the /cygdrive dir (unless your cygdrive prefix is
> / only) is this:

> $ ls /cygdrive
> $ ls -lG /mnt
> total 16
> d---r-x---+ 1 TrustedInstaller  0 Apr 29 21:07 c
> drwxr-xr-x  1 corinna           0 Dec 31  1979 e
> lrwxrwxrwx  1 corinna          32 May  6 20:43 t -> /cygdrive/c/cygwin64/home/corinna/tmp

> I uploaded new developer snapshots to https://cygwin.com/snapshots/
> for testing.

Interesting effect.
I do have fstab entry
none / cygdrive noacl,binary,nouser,posix=0 0 0
And this is what I see with and without changes.

(3.2.0)
$ ls -ld /proc/cygdrive/{a..z} 2> /dev/null
drwxr-x--- 1 anrdaemon None 0 апр 22 23:12 /proc/cygdrive/c
drwxr-x--- 1 anrdaemon None 0 апр 30 18:05 /proc/cygdrive/d
drwxr-x--- 1 anrdaemon None 0 апр 22 23:11 /proc/cygdrive/e
drwxr-x--- 1 anrdaemon None 0 май 11 21:27 /proc/cygdrive/w
drwxr-x--- 1 anrdaemon None 0 фев 14  2018 /proc/cygdrive/y
drwxr-x--- 1 anrdaemon None 0 май 12 03:59 /proc/cygdrive/z

(snapshot)
$ ls -ld /proc/cygdrive/{a..z} 2> /dev/null
drwxr-x--- 1 anrdaemon None  0 апр 22 23:12 /proc/cygdrive/c
drwxr-x--- 1 anrdaemon None  0 апр 30 18:05 /proc/cygdrive/d
drwxr-x--- 1 anrdaemon None  0 апр 22 23:11 /proc/cygdrive/e
drwxr-x--- 1 anrdaemon None  0 май 11 21:27 /proc/cygdrive/w
lrwxrwxrwx 1 anrdaemon None 35 фев 14  2018 /proc/cygdrive/y -> //HOSTING64.DARKDRAGON.LAN/wwwroot/
lrwxrwxrwx 1 anrdaemon None 35 май 12 03:59 /proc/cygdrive/z -> //DAEMON1.DARKDRAGON.LAN/anrdaemon/

I think I like these changes.
Thank you very much.


-- 
With best regards,
Andrey Repin
Wednesday, May 12, 2021 10:04:43

Sorry for my terrible english...

Re: realpath issue with native[strict] symlinks

[Corinna Vinschen]

On May  9 14:35, Orgad Shaneh via Cygwin wrote:
> On Sat, May 8, 2021 at 12:20 AM Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> >
> > I reworked the code handling native symlinks to handle virtual drives
> > as well.  It might even be a tiny bit quicker now.
> >
> > The changes have a behavioral change, but I think this is for the
> > better: Virtual drives are not treated as drives anymore, but as
> > symlinks.  Given they are just pointers to other drives or directories,
> > tha't much closer to reality.  I. e., in case of my above virtual drive
> > T:, what you'll see in the /cygdrive dir (unless your cygdrive prefix is
> > / only) is this:
> >
> > $ ls /cygdrive
> > $ ls -lG /mnt

d'oh

Make that

    $ ls -lG /cygdrive

> > total 16
> > d---r-x---+ 1 TrustedInstaller  0 Apr 29 21:07 c
> > drwxr-xr-x  1 corinna           0 Dec 31  1979 e
> > lrwxrwxrwx  1 corinna          32 May  6 20:43 t -> /cygdrive/c/cygwin64/home/corinna/tmp
> >
> > I uploaded new developer snapshots to https://cygwin.com/snapshots/
> > for testing.
> 
> Thank you very much. Looks good.
> 
> - Orgad

Thanks for testing,
Corinna

Re: realpath issue with native[strict] symlinks

[Orgad Shaneh]

On Sat, May 8, 2021 at 12:20 AM Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:
>
> I reworked the code handling native symlinks to handle virtual drives
> as well.  It might even be a tiny bit quicker now.
>
> The changes have a behavioral change, but I think this is for the
> better: Virtual drives are not treated as drives anymore, but as
> symlinks.  Given they are just pointers to other drives or directories,
> tha't much closer to reality.  I. e., in case of my above virtual drive
> T:, what you'll see in the /cygdrive dir (unless your cygdrive prefix is
> / only) is this:
>
> $ ls /cygdrive
> $ ls -lG /mnt
> total 16
> d---r-x---+ 1 TrustedInstaller  0 Apr 29 21:07 c
> drwxr-xr-x  1 corinna           0 Dec 31  1979 e
> lrwxrwxrwx  1 corinna          32 May  6 20:43 t -> /cygdrive/c/cygwin64/home/corinna/tmp
>
> I uploaded new developer snapshots to https://cygwin.com/snapshots/
> for testing.

Thank you very much. Looks good.

- Orgad

Re: realpath issue with native[strict] symlinks

[Corinna Vinschen]

On May  6 21:36, Orgad Shaneh via Cygwin wrote:
> On Thu, May 6, 2021 at 8:44 PM Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> >
> > On May  4 22:52, Orgad Shaneh via Cygwin wrote:
> > > On Tue, Apr 27, 2021 at 8:44 AM Orgad Shaneh <orgads@gmail.com> wrote:
> > > >
> > > > On Apr 19 12:58, Corinna Vinschen via Cygwin wrote:
> > > > > On Apr 18 10:59, Orgad Shaneh via Cygwin wrote:
> > > >
> > > > > I was going to write:
> > > > >
> > > > >   Nothing we can do about without re-implementing Cygwin's path handling
> > > > >   from scratch.  For historical reasons, POSIX paths are evaluated in a
> > > > >   non-POSIXy manner from right to left.  If the resulting path is an
> > > > >   existing path, the assumption is that no inner path component is a
> > > > >   symlink.  That's true as long as Windows didn't support
> > > > >   symlinks/junctions and Cygwin didn't support them.
> > > > >
> > > > > But now I'm writing this:
> > > > >
> > > > >   Probably I have a workaround for this problem.  I added a certain test
> > > > >   to the function checking the outer path component, so the checks for
> > > > >   path validity don't stop at the outer path component, just because
> > > > >   it's a valid Windows path.
> > > > >
> > > > > I pushed the patch and uploaded new developer snapshots to
> > > > > https://cygwin.com/snapshots/
> > > > >
> > > > > Please give them a try.
> > > >
> > > > Tried now, and it works for me. Thanks a lot!
> > > >
> > > > - Orgad
> > >
> > >
> > > Hi Corinna,
> > >
> > > This change breaks access to subst drives. Reported on MSYS2:
> > > https://github.com/msys2/msys2-runtime/pull/38#issuecomment-832160980
> > >
> > > Can you please have a look?
> >
> > Works fine for me:
> >
> >   $ subst T: C:\\cygwin64\\home\\corinna\\tmp
> >   $ subst
> >   T:\: => C:\cygwin64\home\corinna\tmp
> >   $ ls /cygdrive/t
> >   bar  cygwin  foo  gawk-5.1.0  ocaml  openssh-8.5p1  recurse  tst
> >
> > TAB completion works, too.
> 
> Right. But if you set / for cygdrive in /etc/fstab it fails:
> none / cygdrive binary,posix=0,user 0 0

I reworked the code handling native symlinks to handle virtual drives
as well.  It might even be a tiny bit quicker now.

The changes have a behavioral change, but I think this is for the
better: Virtual drives are not treated as drives anymore, but as
symlinks.  Given they are just pointers to other drives or directories,
tha't much closer to reality.  I. e., in case of my above virtual drive
T:, what you'll see in the /cygdrive dir (unless your cygdrive prefix is
/ only) is this:

$ ls /cygdrive
$ ls -lG /mnt
total 16
d---r-x---+ 1 TrustedInstaller  0 Apr 29 21:07 c
drwxr-xr-x  1 corinna           0 Dec 31  1979 e
lrwxrwxrwx  1 corinna          32 May  6 20:43 t -> /cygdrive/c/cygwin64/home/corinna/tmp

I uploaded new developer snapshots to https://cygwin.com/snapshots/
for testing.


Thanks,
Corinna

Re: realpath issue with native[strict] symlinks

[Orgad Shaneh]

On Thu, May 6, 2021 at 8:44 PM Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:
>
> On May  4 22:52, Orgad Shaneh via Cygwin wrote:
> > On Tue, Apr 27, 2021 at 8:44 AM Orgad Shaneh <orgads@gmail.com> wrote:
> > >
> > > On Apr 19 12:58, Corinna Vinschen via Cygwin wrote:
> > > > On Apr 18 10:59, Orgad Shaneh via Cygwin wrote:
> > >
> > > > I was going to write:
> > > >
> > > >   Nothing we can do about without re-implementing Cygwin's path handling
> > > >   from scratch.  For historical reasons, POSIX paths are evaluated in a
> > > >   non-POSIXy manner from right to left.  If the resulting path is an
> > > >   existing path, the assumption is that no inner path component is a
> > > >   symlink.  That's true as long as Windows didn't support
> > > >   symlinks/junctions and Cygwin didn't support them.
> > > >
> > > > But now I'm writing this:
> > > >
> > > >   Probably I have a workaround for this problem.  I added a certain test
> > > >   to the function checking the outer path component, so the checks for
> > > >   path validity don't stop at the outer path component, just because
> > > >   it's a valid Windows path.
> > > >
> > > > I pushed the patch and uploaded new developer snapshots to
> > > > https://cygwin.com/snapshots/
> > > >
> > > > Please give them a try.
> > >
> > > Tried now, and it works for me. Thanks a lot!
> > >
> > > - Orgad
> >
> >
> > Hi Corinna,
> >
> > This change breaks access to subst drives. Reported on MSYS2:
> > https://github.com/msys2/msys2-runtime/pull/38#issuecomment-832160980
> >
> > Can you please have a look?
>
> Works fine for me:
>
>   $ subst T: C:\\cygwin64\\home\\corinna\\tmp
>   $ subst
>   T:\: => C:\cygwin64\home\corinna\tmp
>   $ ls /cygdrive/t
>   bar  cygwin  foo  gawk-5.1.0  ocaml  openssh-8.5p1  recurse  tst
>
> TAB completion works, too.

Right. But if you set / for cygdrive in /etc/fstab it fails:
none / cygdrive binary,posix=0,user 0 0

- Orgad

Re: realpath issue with native[strict] symlinks

[Corinna Vinschen]

On May  4 22:52, Orgad Shaneh via Cygwin wrote:
> On Tue, Apr 27, 2021 at 8:44 AM Orgad Shaneh <orgads@gmail.com> wrote:
> >
> > On Apr 19 12:58, Corinna Vinschen via Cygwin wrote:
> > > On Apr 18 10:59, Orgad Shaneh via Cygwin wrote:
> >
> > > I was going to write:
> > >
> > >   Nothing we can do about without re-implementing Cygwin's path handling
> > >   from scratch.  For historical reasons, POSIX paths are evaluated in a
> > >   non-POSIXy manner from right to left.  If the resulting path is an
> > >   existing path, the assumption is that no inner path component is a
> > >   symlink.  That's true as long as Windows didn't support
> > >   symlinks/junctions and Cygwin didn't support them.
> > >
> > > But now I'm writing this:
> > >
> > >   Probably I have a workaround for this problem.  I added a certain test
> > >   to the function checking the outer path component, so the checks for
> > >   path validity don't stop at the outer path component, just because
> > >   it's a valid Windows path.
> > >
> > > I pushed the patch and uploaded new developer snapshots to
> > > https://cygwin.com/snapshots/
> > >
> > > Please give them a try.
> >
> > Tried now, and it works for me. Thanks a lot!
> >
> > - Orgad
> 
> 
> Hi Corinna,
> 
> This change breaks access to subst drives. Reported on MSYS2:
> https://github.com/msys2/msys2-runtime/pull/38#issuecomment-832160980
> 
> Can you please have a look?

Works fine for me:

  $ subst T: C:\\cygwin64\\home\\corinna\\tmp
  $ subst
  T:\: => C:\cygwin64\home\corinna\tmp
  $ ls /cygdrive/t
  bar  cygwin  foo  gawk-5.1.0  ocaml  openssh-8.5p1  recurse  tst

TAB completion works, too.


Corinna

Re: realpath issue with native[strict] symlinks

[Orgad Shaneh]

On Tue, Apr 27, 2021 at 8:44 AM Orgad Shaneh <orgads@gmail.com> wrote:
>
> On Apr 19 12:58, Corinna Vinschen via Cygwin wrote:
> > On Apr 18 10:59, Orgad Shaneh via Cygwin wrote:
>
> > I was going to write:
> >
> >   Nothing we can do about without re-implementing Cygwin's path handling
> >   from scratch.  For historical reasons, POSIX paths are evaluated in a
> >   non-POSIXy manner from right to left.  If the resulting path is an
> >   existing path, the assumption is that no inner path component is a
> >   symlink.  That's true as long as Windows didn't support
> >   symlinks/junctions and Cygwin didn't support them.
> >
> > But now I'm writing this:
> >
> >   Probably I have a workaround for this problem.  I added a certain test
> >   to the function checking the outer path component, so the checks for
> >   path validity don't stop at the outer path component, just because
> >   it's a valid Windows path.
> >
> > I pushed the patch and uploaded new developer snapshots to
> > https://cygwin.com/snapshots/
> >
> > Please give them a try.
>
> Tried now, and it works for me. Thanks a lot!
>
> - Orgad


Hi Corinna,

This change breaks access to subst drives. Reported on MSYS2:
https://github.com/msys2/msys2-runtime/pull/38#issuecomment-832160980

Can you please have a look?

Please CC me when you reply. I'm not on the mailing list.

Thank you,
- Orgad

Re: realpath issue with native[strict] symlinks

[Orgad Shaneh]

On Apr 19 12:58, Corinna Vinschen via Cygwin wrote:
> On Apr 18 10:59, Orgad Shaneh via Cygwin wrote:

> I was going to write:
>
>   Nothing we can do about without re-implementing Cygwin's path handling
>   from scratch.  For historical reasons, POSIX paths are evaluated in a
>   non-POSIXy manner from right to left.  If the resulting path is an
>   existing path, the assumption is that no inner path component is a
>   symlink.  That's true as long as Windows didn't support
>   symlinks/junctions and Cygwin didn't support them.
>
> But now I'm writing this:
>
>   Probably I have a workaround for this problem.  I added a certain test
>   to the function checking the outer path component, so the checks for
>   path validity don't stop at the outer path component, just because
>   it's a valid Windows path.
>
> I pushed the patch and uploaded new developer snapshots to
> https://cygwin.com/snapshots/
>
> Please give them a try.

Tried now, and it works for me. Thanks a lot!

- Orgad