Re: Strange behavior when executing programs

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Dec 12 13:46, Frank Redeker via Cygwin wrote:
> Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen:
> > On Dec 12 11:21, Frank Redeker via Cygwin wrote:
> > > $ pwd
> > > /cygdrive/s/ado
> > > 
> > > $ realpath /cygdrive/s/ado/msadox.dll
> > > /cygdrive/s/ado/msadox.dll
> > > 
> > > $ realpath msadox.dll
> > > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll
> > > 
> > > 
> > > Is there any way to restore the old behavior. Since with the new behavior my
> > > tests no longer work.
> > 
> > It's not easy.  If we remove the new behaviour entirely, we break
> > other scenarios which were broken in the old version.  While it
> > *seems* easy to fix your specific scenario, it will break again
> > as soon as the substitution drive is used inside a native symlink.
> > 
> > Virtual drive letters were always a problem and it doesn't get easier
> > with Windows functions not allowing to specify whether one wants to
> > follow symlinks or virt drives in inner path components or not.
> > 
> > Let's consider this problem again, but I don't see a quick and easy
> > solution.
> > 
> > 
> > Corinna
> Hello Corinna, I am willing to create my own version, tailored to my needs.

Before you do that and decouple yourself from development, I'd suggest
to look for a workaround in your code, or to see if we can't patch this
behaviour in the upstream code.

> It would be nice if you could provide me with the commit that was used to
> implement the new behavior. (I guess the change is found inside the
> *git://sourceware.org/git/newlib-cygwin.git* repository)

Yes, but it's a group of patches trying to fix native symlink behaviour,
spread over a couple of iterations.  If you're looking for an easy
workaround for your case, try this:

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index e7619270a269..131c7e88278f 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -3492,8 +3492,10 @@ restart:
 	        {
 		  /* Check if the final path is an UNC path and the incoming
 		     path isn't.  If so... */
-		  if (RtlEqualUnicodePathPrefix (&fpath, &ro_u_uncp, TRUE)
-		      && !RtlEqualUnicodePathPrefix (&upath, &ro_u_uncp, TRUE))
+		  if (!RtlEqualUnicodePathPrefix (&upath, &ro_u_uncp, TRUE)
+		      && (RtlEqualUnicodePathPrefix (&fpath, &ro_u_uncp, TRUE)
+			  || towupper (upath.Buffer[4])
+			     != towupper (fpath.Buffer[4])))
 		    {
 		      /* ...get the remote path, replace remote path
 			 with drive letter, check again. */

However, a generic solution would be preferrable, and a local patch
to your scripts would be the better workaround for now.


Corinna