Bug 10532 - Rsync fails with older version.
Summary: Rsync fails with older version.
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.1
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
: 10571 11803 (view as bug list)
Depends on:
Reported: 2014-04-01 15:40 UTC by Roger Wolff
Modified: 2016-06-15 06:08 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Roger Wolff 2014-04-01 15:40:39 UTC
Does not work:
Trusty Tahr.
Rsync version 3.1.0
Protocol version 31

DOES work:
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).
Comment 1 rafael.turk 2014-04-24 10:30:42 UTC
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]
Comment 2 Wayne Davison 2014-04-24 15:33:28 UTC
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.
Comment 3 Roger Wolff 2014-04-27 10:17:59 UTC
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".
Comment 4 Wayne Davison 2014-04-29 17:13:13 UTC
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.
Comment 5 Wayne Davison 2014-04-29 17:16:07 UTC
*** Bug 10571 has been marked as a duplicate of this bug. ***
Comment 6 Wayne Davison 2014-04-29 17:52:49 UTC
Oops, I meant to say --protocol=30 (not --version).
Comment 7 John Jacq 2014-04-29 18:58:19 UTC
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.
Comment 8 Roger Wolff 2014-04-30 07:40:41 UTC
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.
Comment 9 Wayne Davison 2016-06-15 05:53:01 UTC
*** Bug 11803 has been marked as a duplicate of this bug. ***
Comment 10 Roger Wolff 2016-06-15 06:08:00 UTC
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.)