As mentioned in the summary, rsync seems to sometimes fail
with "rsync: unrecognized option `--max-delete=1000000000'"
Of course, to make it interesting, it should be noted that
this option is _not_ part of the commandline, and is not
part of an alias.
[alikins@slag RDF]$ which rsync
[alikins@slag RDF]$ /usr/bin/rsync --delete -r -v --rsh=/usr/bin/ssh .
rsync: unrecognized option `--max-delete=1000000000'
unexpected EOF in read_timeout
rsync seem to rebuild its commandline sometimes to
include the "--max-delete=100000000" even if you didnt
specify it, then execve's the new commandline. Very weird.
To make it more fun, sometimes it will work on other directories,
but fail if straced.
[alikins@slag /tmp]$ /usr/bin/rsync --delete -r -v --rsh=/usr/bin/ssh .
but stracing it will cause the error above as well.
Sometimes it works, sometimes it doesnt.
Also note, that despite what the output of `rsync -h` claims,
giving "--max-delete=1000" on the commandline doesnt work either.
I'll attach a strace...
Created attachment 139 [details]
strace showing rsync freaking out
The max-delete option was a patch from Daniel Veillard to minimize
damage when the source of a rsync had, for example, "disk problems".
I believe that the patch has been rolled into the latest rsync, albeit
with syntax changes. Judging from rsync traffic, there may be other
problems with rsync-2.4.1, so an update/errata will probably be necessary.
As a work around, you can always install the 6.1 package with Daniel Veillard's
Um, your strace is broken and dying because it's trying
to exec ssh under strace (ssh is setuid, so it won't work.)
The error you are getting is from the rsync process
running on the other end of the connection. Upgrading
rsync on that end should stop the problem.
*** Bug 9995 has been marked as a duplicate of this bug. ***
Fixed in rsync-2.4.1-2.