fix: rsync uploads fail on openrsync ("empty remote host")#10
Merged
Conversation
sync_uploads() built rsync's --rsh by reusing generate_ssh_command(), which returns an already shell-escaped command; routing that through assoc_args_to_str escaped it a second time. GNU rsync strips the extra quotes, but openrsync (the /usr/bin/rsync on macOS 15+ and the BSDs) does not, so the literal quotes reached ssh and the host failed to resolve -- breaking uploads on those environments. Build a transport-only `ssh -T [-p port] [-i key]` escaped exactly once, and pass the host via the standard [user@]host:path location instead of baking it into --rsh with an empty-host ':path' target. -T also keeps rsync's binary stream off a TTY. generate_ssh_command() is unchanged and still used by run_command and export_db. Refs: sync uploads fail on openrsync (macOS 15+/BSD)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Syncing uploads fails on some machines with:
sync_uploads()pointed rsync at a target like':/…/uploads/'— an empty host before the colon — with the real host baked into--rsh(ssh … 'user@host'). GNU rsync tolerates the empty host (it falls back to the host in the rsh command), so it works on Linux and Homebrew rsync. But openrsync — the/usr/bin/rsyncApple ships on macOS 15+, and the BSDs — validates the target and rejects an empty remote host outright, before it even runs the transport.Two related fragilities in the same construction:
--rshvalue was double shell-escaped —generate_ssh_command()returns an already-escaped command, thenassoc_args_to_str()escaped it again. GNU rsync's-eparser peels the extra quotes back off; stricter parsers may not.-t(request a TTY), inherited fromgenerate_ssh_command()'s interactive-wppurpose, which is wrong for rsync's binary stream.Fix
Build the rsync invocation directly instead of reusing
generate_ssh_command():Alias::get_rsync_location()— a standard[user@]host:pathlocation, so the host is always explicit (no empty-host target).Alias::get_rsync_rsh()— a transport-onlyssh -T [-p port] [-i key], escaped exactly once;-Tkeeps rsync's stream off a TTY.generate_ssh_command()is unchanged and still used byrun_command()/export_db().Before / after
Testing
RequestTTY forcessh_config; the standarduser@host:pathform transfers and verifies by checksum.rsync: empty remote host) reported by a macOS user.Follow-up
get_rsync_rsh()/get_rsync_location(), plus a forced-TTY fix forexport_db(), are in a follow-up branch.proxyjumpis not carried into the transport (it was already unused for rsync —Alias::create()never captured it), so no regression; trivial to add if needed.