public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* realpath issue with native[strict] symlinks
@ 2021-05-27 20:21 Jeremy Drake
  2021-05-28 19:23 ` Jeremy Drake
  0 siblings, 1 reply; 18+ messages in thread
From: Jeremy Drake @ 2021-05-27 20:21 UTC (permalink / raw)
  To: cygwin

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: realpath issue with native[strict] symlinks
@ 2021-05-18 20:01 Jeremy Drake
  2021-05-19 12:42 ` Corinna Vinschen
  0 siblings, 1 reply; 18+ messages in thread
From: Jeremy Drake @ 2021-05-18 20:01 UTC (permalink / raw)
  To: cygwin

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* realpath issue with native[strict] symlinks
@ 2021-05-15  4:12 Jeremy Drake
  2021-05-17 10:12 ` Corinna Vinschen
  0 siblings, 1 reply; 18+ messages in thread
From: Jeremy Drake @ 2021-05-15  4:12 UTC (permalink / raw)
  To: cygwin; +Cc: Orgad Shaneh

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: realpath issue with native[strict] symlinks
@ 2021-04-27  5:44 Orgad Shaneh
  2021-05-04 19:52 ` Orgad Shaneh
  0 siblings, 1 reply; 18+ messages in thread
From: Orgad Shaneh @ 2021-04-27  5:44 UTC (permalink / raw)
  To: corinna-cygwin, cygwin

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* realpath issue with native[strict] symlinks
@ 2021-04-18  7:59 Orgad Shaneh
  2021-04-19 12:58 ` Corinna Vinschen
  0 siblings, 1 reply; 18+ messages in thread
From: Orgad Shaneh @ 2021-04-18  7:59 UTC (permalink / raw)
  To: cygwin

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-06-08  0:01 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-27 20:21 realpath issue with native[strict] symlinks Jeremy Drake
2021-05-28 19:23 ` Jeremy Drake
2021-06-08  0:01   ` Jeremy Drake
  -- strict thread matches above, loose matches on Subject: below --
2021-05-18 20:01 Jeremy Drake
2021-05-19 12:42 ` Corinna Vinschen
2021-05-15  4:12 Jeremy Drake
2021-05-17 10:12 ` Corinna Vinschen
2021-04-27  5:44 Orgad Shaneh
2021-05-04 19:52 ` Orgad Shaneh
2021-05-06 17:44   ` Corinna Vinschen
2021-05-06 18:36     ` Orgad Shaneh
2021-05-07 21:20       ` Corinna Vinschen
2021-05-09 11:35         ` Orgad Shaneh
2021-05-10  7:50           ` Corinna Vinschen
2021-05-12  7:10         ` Andrey Repin
2021-05-12  8:14           ` Corinna Vinschen
2021-04-18  7:59 Orgad Shaneh
2021-04-19 12:58 ` Corinna Vinschen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).