Rsync fails with (very) old server.

[rew]

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.

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I think the appropriate next step to take with this bug would be to try and reproduce this with rsync built from the upstream tarball, with no distribution packaging.

If it still does not work with the latest upstream, then this bug will need to go upstream.

If this cannot be reproduced with a clean upstream binary, then we'll need to investigate what broke this in Ubuntu.

Are you able to test this case, please?

[rew (r-e-wolff)]

I got the git upstream sources.
I used "git bisect" for the first time.
Out of 356 commits between 3.0.9 and the current version....

[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.

.... is the one that causes the problem.

[Robie Basak (racb)]

Thanks! It's not completely clear to me. Did you find that the latest git HEAD does have the problem? If so, then it looks to me that this is either an upstream bug or done by design upstream. For both of those cases, I don't think we'll be able to do anything about this in Ubuntu directly, but we could cherry-pick something from upstream if they decided it was a bug and fixed it.

Alternatively, is there some other solution you have in mind?

[rew (r-e-wolff)]

Yes, the git HEAD also has the problem. You are right. "upstream bug / by design". I'd think the first, because the commit comment doesn't say "break compatibility with V21 protocol".

For me personally I need to be able to rsync to/from the ancient machine this week. I just need to remember to do this from the non 14.04 machines that I have. It's inconvenient, since some of the rsyncs that I need go to a partition that isn't mounted on the non-14.04 machines. So it will have to become a two-step procedure. But that's my workaround. I'll manage.

I report bugs like this with the intention to help fix it for the future. When I run into a similar situation again in the future, I prefer to have helped get it fixed as opposed to running into the problems again.

I'm guessing that some new feature in the protocol was not properly surrounded with "if (negotiatedprotocol > xxx) .."

[Robie Basak (racb)]

Thank you for investigating this.

> I report bugs like this with the intention to help fix it for the future. When I run into a similar situation again in the future, I prefer to have helped get it fixed as opposed to running into the problems again.

Understood, and we appreciate this. Please do continue to report bugs in this fashion.

> I'm guessing that some new feature in the protocol was not properly surrounded with "if (negotiatedprotocol > xxx) .."

It seems to me that this might be a mistake, and not done on purpose. If you can take this further, perhaps you could check to see if upstream know about this issue already, and if not then raise it in their bug tracker?

I'll mark this as Invalid in Ubuntu on the assumption that this is intentional behaviour, but if it turns out that it isn't, and there's a fix, we can always change this.