Does not work: Trusty Tahr. Rsync version 3.1.0 Protocol version 31 DOES work: Saucy rsync version 3.0.9 protocol version 30 In both cases: "server side": Suse 7.0 version 2.3.2 protocol version 21 with both "client" side rsyncs I of course get: > Server is very old version of rsync, upgrade recommended. but with the newer rsync I get: Warning: No xauth data; using fake authentication data for X11 forwarding. Server is very old version of rsync, upgrade recommended. protocol version mismatch - is your shell clean? (see the rsync man page for an explanation) rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.0] According to the manpage I can test the "is your shell clean" with ssh oldserver /usr/bin/true > out.dat but I get a clean file (0 bytes). I just checked: the "no xauth data" doesn't matter: rsync -e "ssh -x" vsuse:/etc/issue . has the same problems. The Ubuntu guys asked me to report this here.... I used "git bisect" for the first time. The commit that caused this problem is: [8b3e60523aa3d86583a1df54c81c9d480ea19740] Improved the fix that ensures that the generator gets notified about an I/O error for the incremental directory that generated the error. The PROTOCOL_VERSION was bumped to 31 to implement this. See https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1300768 for my original ubuntu bugreport. (but mostly copy-pasted here).
Same error when using Mac OS protocol version mismatch -- is your shell clean? (see the rsync man page for an explanation) rsync error: protocol incompatibility (code 2) at compat.c(174) [sender=3.1.0]
rsync 2.3.2 won't interact with protocol 31 -- it is too great of a protocol number for it. You should upgrade that super-old rsync. Alternately, you can specify a protocol number on the client's command-line to make the old-rsync happier.
My arguments for seeing this as a bug are: 1) The rsync version of half a year ago /is/ able to communicate with that old version. 2) The patch comment for the patch that "removed" compatiblity did not mention that it would break compatiblity. 3) I encountered this when ubuntu trusty-tahr would not rsync with suse 7.0, but Saucy Salamander would. Thus the incompatiblity was introduced quite recent. Having the ability to copy files to and from older systems (real or virtual) is useful. Suppose I saved the disk from an older system and now want to recover the files from it. Boot an old motherboard with the harddrive and just rsync the files is very useful. Oh. Just connect the drive to a system and copy the files? Yeah. Maybe thats sometimes quicker. In the case at hand, I had to run some very old software, that wouldn't run on a more modern distribution. (or at least, I knew it ran on THAT old distribution, and I managed to "fast-forward" eventually to find the latest versions that would work.) Getting modern software to compile and run on an older distribution is troublesome. Try and upgrade a package like SAMBA to the latest version on a "still supported" LTS release (e.g. Ubuntu 10.04 Lucid Lynx LTS). Now if there is a fundamental issue with the protocol I understand that at one point you have to break the backwards compatiblity. But in incrementing the protocol version number from 31 to 32 I don't see a fundamental reason reason to break protocol V21 compatibilily. It's probably some typo that causes things to go awry and not a fundamental issue. For something like "ssh" I could understand a: "protocol version is too old. That version has fundamental security issues. Specify --force to force the connection".
Rsync 2.3.2 refuses to interact with protocol 31. If you wish to tweak 2.3.2 to not be so draconian, please be my guest, but you'd be better off upgrading the hugely ancient rsync instead. There's nothing that a modern rsync can do about the refusal of an old rsync to interact with it since it must advertise its maximum protocol (and it doesn't know how old the server is beforehand). More modern rsyncs are more forgiving about allowing later versions, but only up to protocol 40 at present. It would be nice to remove the max-protocol check altogether, but the check was added to try to figure out when it received some ascii garbage instead of a valid protocol value, so we need a better "I got garbage" check (which should really have been implemented in a better manner from the start). So, if you run into an old rsync and you can't upgrade it, just remember to use --version=30 to work around its deficiency.
*** Bug 10571 has been marked as a duplicate of this bug. ***
Oops, I meant to say --protocol=30 (not --version).
Thanks, this does work fine. I've simply aliased rsync to "rsync --protocol=30" in my .bash_aliases file so as not to change my backup scripts. Updating rsync on the remote machine would be better but I'm not the administrator.
Ah! It is the OLDER version of rsync that is refusing to talk to the newer one. I would always have implemented protocol version compatiblity by having the newer version make the decision.
*** Bug 11803 has been marked as a duplicate of this bug. ***
FYI: I still think this is relevant, and the current "structure" is not appropriate. The machine in question was installed in 1996, it serves a single purpose (in an industrial environment) and it serves it well. But for maintenance it is useful to be able to copy files in and out of that machine..... (back then... I managed to convince the powers-that-be that it was NOT appropriate to arrange an internet connection for that machine... So it is NOT on the internet... Thank god.)