Assume my home directory on 'remote' has no files matching '*4'. Now run this: remote$ touch ./-zT.mp4 local$ mkdir test local$ cd test local$ rsync -zavPH --numeric-ids -S --stats '--rsh=ssh -T' $remote:\*4 . Expected: the “-zT.mp4” file is transferred. Actual: the whole home directory of $remote, including subdirectories and everything, is transferred. Now imagine I had not cd’d into a new subdirectory. I have overwritten all files in my own home directory that are present on remote’s before I managed to press ^C and lost my TODO file and some dotfiles. Yes, files starting with a U+002D HYPHEN-MINUS are problematic. I’d still expect files that have passed muster on the local side to be properly escaped to the remote side. I think this is simply a case of a missing “--” argument before the pathnames on the constructed rsh command line. When I do… $ rsync -zavPH --numeric-ids -S --stats '--rsh=logger --' localhost:\* . … I get this in syslog: localhost rsync --server --sender -vlHogDtprSze.iLsfxC --numeric-ids . * Now if after --numeric-ids there was a -- I believe the problem would go away. (I’m aware of rsync’s capability to apply remote globs, and this is not the problem here; in fact, the first command of mine above relies on that. This is strictly about the hyphen-minus, which is not uncommon in filenames created by youtube-dl.)
Please try again with the --protect-args option, which is meant for such situations. BTW, why specify '--rsh=ssh -T', what's wrong with the default? Paul
Paul Slootman dixit:
Ah, new post-2.x… *tries*
No change, this still transfers the entire home directory.
I think it’s meant for something else (I usually do quote
whitespace and so on for remote if necessary).
The default can be anything, including rsh. By specifying this
always, I know that ⓐ ssh is called, ⓑ -T is passed which makes
ssh change its QoS from interactive to bulk, and ⓒ can add -4
or -6 to force the IP protocol version (I recently learnt that
Debian has a local patch to pass -4/-6 from rsync to ssh, but
Debian’s isn’t the only package I use). I always use a wrapper
around rsync calling it like this (incidentally called rcp…).
bye,
//mirabilos
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine
I think you just need to prefix your wildcard. This works for me:
$ rsync -zavP --numeric-ids --stats $remote:./*4 .
receiving incremental file list
-zT.mp4
0 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1)
Number of files: 1 (reg: 1)
Number of created files: 1 (reg: 1)
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 0 bytes
Total transferred file size: 0 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 37
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 43
Total bytes received: 88
sent 43 bytes received 88 bytes 262.00 bytes/sec
total size is 0 speedup is 0.00
It does work. Almost any insufficient quoting can be worked around by the user applying extra quoting to the command line; this is not a reason to not classify this as a bug with the capability to destroy user data, though. The fix is *probably* easy enough, separate the arguments from the options by “--” on the command line that is passed to the remote side (then apply extra escaping for ssh, of course). bye, //mirabilos
Hi, Any updates?
Control: severity -1 normal Since there wasn’t any activity on this bug, and there’s no sign of this to be fixed any time soon, and rsync provides ways to work this around, I don’t think having this bug marked as serious is justified. If you disagree, please comment/update.
Hello Thorsten, since version 3.2.4 rsync does use the "escaped argument protocol", which is similar to the behavior of --protected-args. In other simplified words: --protected-args is now the default in rsync. Any objections against closing the issue 8 years after the last comment? Regards, Christian Buhtz