Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
1 task done
Zsar opened this issue Jan 9, 2025 · 3 comments
Open
1 task done
Labels

Comments

@Zsar
Copy link

Zsar commented Jan 9, 2025

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

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 Zsar added the bug label Jan 9, 2025
@Zsar
Copy link
Author

Zsar commented Jan 10, 2025

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
Copy link
Author

Zsar commented Jan 13, 2025

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
Copy link
Author

Zsar commented Jan 13, 2025

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant