Strange behavior of MSYS shell version 5.1.8

[der-appit]

I have a strange behavior when the executing a program in a MSYS shell version 5.1.8. I'm on Windows 10 Version 22H2 (OS Build 19045.2251). The strange behavior occurs when current directory is on a drive created with subst.

The following steps can be used to reproduce the behavior.

Inside a Windows CMD

C:\Users\f.redeker>subst s: "C:\Program Files\Common Files\System"
C:\Users\f.redeker>subst
S:\: => C:\Program Files\Common Files\System

Inside a shell version 5.1.8

sh-5.1$ uname -a
MSYS_NT-10.0-18362 MIMIR-W10-64 3.2.0-340.x86_64 2021-07-02 08:36 UTC x86_64 Msys

sh-5.1$ sh --version
GNU bash, version 5.1.8(1)-release (x86_64-pc-msys)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

sh-5.1$ realpath /s/ado/msadox.dll
/s/ado/msadox.dll

sh-5.1$ cd /s
sh-5.1$ pwd
/s

sh-5.1$ realpath ado/msadox.dll
/s/ado/msadox.dll

sh-5.1$ cd ado
sh-5.1$ pwd
/s/ado

sh-5.1$ realpath msadox.dll
/c/Program Files/Common Files/System/ado/msadox.dll

But

sh-5.1$ realpath /s/ado/sadox.dll
/s/ado/msadox.dll

Inside a shell version 4.4.19

sh-4.4$ uname -a
MSYS_NT-10.0-18362 MIMIR-W10-64 3.2.0-340.x86_64 2021-07-02 08:36 UTC x86_64 Msys

sh-4.4$ sh --version
GNU bash, version 4.4.19(2)-release (i686-pc-msys)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

sh-4.4$ cd /s
sh-4.4$ pwd
/s

sh-4.4$ realpath ado/msadox.dll
/s/ado/msadox.dll

sh-4.4$ cd ado
sh-4.4$ pwd
/s/ado

`sh-4.4$ realpath msadox.dll
/s/ado/msadox.dll

With Process Monitor I have observed that the shell does not directly start the program to be executed, but first another shell. When creating this shell it seems that the current directory is given when CreateProcess is called. Here, however, not the path with the subst drive (S:\ado) is used but the one to which the subst drive points (C:\Program Files\Common Files\System\ado). Due to this behavior the Windows functions (e.g. _fullpath or GetFullPathName) do not return the result with the subst path if not an absolute path is specified as input parameter.

Is there any way to preserve the old behavior in the current MSYS version?

[elieux]

Can you check how Cygwin behaves in the same situation?

[der-appit]

Can you check how Cygwin behaves in the same situation?

On a computer with an older version.

$ uname -a
CYGWIN_NT-6.1-WOW Mimir 2.9.0(0.318/5/3) 2017-09-12 10:41 i686 Cygwin

$ sh --version
GNU bash, version 4.4.12(3)-release (i686-pc-cygwin)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ pwd
/cygdrive/s/ado

$ realpath /cygdrive/s/ado/msadox.dll
/cygdrive/s/ado/msadox.dll

$ realpath msadox.dll
/cygdrive/s/ado/msadox.dll

`
On a computer with a more actual version,

$ uname -a
CYGWIN_NT-10.0-19045 MIMIR-2 3.3.6-341.x86_64 2022-09-05 11:15 UTC x86_64 Cygwin

$ sh --version
GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ 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

[elieux]

So we can infer that Bash is definitely not the only factor, but I'm not sure what would be the difference. Is your msys2-runtime the same version in the original test?

(edited to fix the above sentence to say "not the only factor" as originally intended)

[elieux]

Nevermind, I guess the uname answers that.

Anyway, I recommend:

• asking Cygwin people
• bisecting to see when exactly the change happened

[elieux]

I asked and Corinna produced this patch: https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=5ba5e09b9d39feaedc9be0dcd88d085b256c5d40

It might fix the inconsistency.

[der-appit]

Yes, this patch cygwin-3.5.0-0.30.g5ba5e09b9d39 solved the problem. I cloned https://github.com/msys2/msys2-runtime, merged Corinna's change into winsup/cygwin/path.cc, and tried to build msys-2.0.dll. (./configure & make). But no DLL was build.
Can someone guide me how to build msys-2.0.dll?