[rsync] MSYS2 rsync prefixes target path with client's MSYS2 installation dir in server command

[Zsar]

Description / Steps to reproduce the issue

1. install rsync 3.3.0 in MSYS2 (downloaded 2025-01-09, installed in default location C:/msys64) on Windows 11
2. grab ssh key of a Linux server with another rsync that supports protocol version 31 (tested: rsync 3.2.7, 3.2.3)
3. prepare a Linux client to compare with (tested: Debian 12)
4. call in both clients: rsync --rsh='ssh -v' -r -v --delete <user>@<server>:<source path> <destination path> >log.txt 2>&1
5. server command sent from Linux client (succeeds): rsync --server --sender -vre.iLsfxCIvu . <source path>
   server command sent from Windows client (fails with code 12): rsync --server --sender -vre.iLsfxCIvu . C:/msys64/<source path>

Expected behavior

The source path should not be altered.

Actual behavior

The source path is prefixed with a directory that will generally not contain the relevant data, even if it exists.
(Actual data even on Windows would not be put into C:/msys64 but e.g. into C:/Users/<user>/Documents.)

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MINGW64_NT-10.0-26100

Are you willing to submit a PR?

Maybe? Should be easy to fix, but I have not checked.

[Zsar]

rsync passes the correct, unaltered argument to execvp in pipe.c:83: execvp(command[0], command);
(It is command[10].)

Apparently this feature is to blame.

Unfortunately the described way to disable it does not work:

$ MSYS2_ARG_CONV_EXCL='*'
$ echo $MSYS2_ARG_CONV_EXCL
*
$ rsync --rsh='/C/Windows/System32/OpenSSH/ssh.exe -v' -r -v --delete <user>@<server>:<source> <destination>
[...]
debug1: Sending command: rsync --server --sender -vre.iLsfxCIvu . C:/msys64/<source>

$ MSYS2_ARG_CONV_EXCL='*' rsync --rsh='/C/Windows/System32/OpenSSH/ssh.exe -v' -r -v --delete <user>@<server>:<source> <destination>
[...]
debug1: Sending command: rsync --server --sender -vre.iLsfxCIvu . C:/msys64/<source>

$ MSYS2_ARG_CONV_EXCL="*" rsync --rsh='/C/Windows/System32/OpenSSH/ssh.exe -v' -r -v --delete <user>@<server>:<source> <destination>
[...]
debug1: Sending command: rsync --server --sender -vre.iLsfxCIvu . C:/msys64/<source>

$ MSYS2_ARG_CONV_EXCL="<user>@<server>" rsync --rsh='/C/Windows/System32/OpenSSH/ssh.exe -v' -r -v --delete <user>@<server>:<source> <destination>
[...]
debug1: Sending command: rsync --server --sender -vre.iLsfxCIvu . C:/msys64/<source>

(I have also tried MSYS2_ENV_CONV_EXCL - had accidentally used that first and then repeated the test with MSYS2_ARG_CONV_EXCL when I noticed.)

Note that this substitution also happens if I call rsync from outside of the MSYS2 environment. That should not happen, as far as the documentation claims:

When calling native executables from the context of Cygwin [...]

[Zsar]

Unlike the documented switches, MSYS_NO_PATHCONV has the desired effect:

$ MSYS_NO_PATHCONV=1 rsync --rsh='/C/Windows/System32/OpenSSH/ssh.exe -v' -r -v --delete <user>@<server>:<source> /C/msys64/<destination>
[...]
debug1: Sending command: rsync --server --sender -vre.iLsfxCIvu . <source>

The connection still closes unexpectedly with code 12, but that is fixed by replacing the Windows-native OpenSSH with the MSYS2-provided one.

... So... is this working-as-intended? I must admit, I am not sure what to do about this situation, but it emphatically does not feel like it's working "correctly".

[Zsar]

A better undocumented workaround, that allows to use the same path string on Windows and Linux, is this one: Just add an additional leading slash to <source>.

As it is not listed in the documentation, is that intended/guaranteed or just an implementation detail that may spuriously change in the future?