Bug 7368 - Multiple --*-dest should still work for exactly matching files when protocol < 29
Summary: Multiple --*-dest should still work for exactly matching files when protocol ...
Status: RESOLVED WONTFIX
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.7
Hardware: Other Linux
: P4 enhancement (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-16 13:45 UTC by Jörg Sommer (mail address dead)
Modified: 2011-11-23 21:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jörg Sommer (mail address dead) 2010-04-16 13:45:49 UTC
I'm synchonizing files with a host that has only rsync version 2.6.3  protocol version 28 installed. I want to use the link-dest option at my side, but rsync refuses to use it, because the negotiated protocol version is to old. But I don't see, why link-dest depends on the protocol. Isn't it an option of a single side?

I think the lookup for files on one side can also happen, when the negotiated protocol version is very old.

If it's not possible, because the link-dest depends on the negotiated protocol version, close this wish report.

Thanks, Jörg
Comment 1 Matt McCutchen 2010-04-16 17:16:10 UTC
--link-dest support was added in rsync 2.5.6, so it should work when talking to rsync 2.6.3.  Please post the exact error output you get.
Comment 2 Jörg Sommer (mail address dead) 2010-04-17 17:49:17 UTC
% rsync -avv --rsync-path='rsync --link-dest=/tmp/bin-o' bin joerg@joerg:/tmp
opening connection using ssh -l joerg joerg "rsync --link-dest=/tmp/bin-o" --server -vvlogDtpr . /tmp 
Using more than one --link-dest option requires protocol 29 or higher (negotiated 28).
rsync error: protocol incompatibility (code 2) at compat.c(240) [Receiver=3.0.7]
rsync: connection unexpectedly closed (4 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(359)

% rsync --version
rsync  version 2.6.3  protocol version 28
Copyright (C) 1996-2004 by Andrew Tridgell and others
<http://rsync.samba.org/>
Capabilities: 64-bit files, socketpairs, hard links, acls, symlinks, batchfiles, 
              inplace, IPv6, 64-bit system inums, 64-bit internal inums, SLP

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.

% ssh joerg rsync --version
rsync  version 3.0.7  protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.
Comment 3 Matt McCutchen 2010-04-17 18:28:25 UTC
(In reply to comment #2)
> Using more than one --link-dest option requires protocol 29 or higher
        ^^^^^^^^^^^^^
This is the key point.  In general, you should provide the output the first time to save a round trip in case you omitted an important fact from your description.

The generator needs to tell the receiver which basis dir contained the basis file to use for each file being received.  Since the protocol is pipelined, the sender's cooperation is needed to relay this information.  With an older sender, there is no way for the delta-transfer algorithm to use basis dirs other than the first.  The generator could probably still handle exactly matching files without sender cooperation, though it might not be able to itemize that correctly.  So this is a valid enhancement request, though it is quite low priority because rsync 2.6.3 is WAY obsolete.

> --rsync-path='rsync --link-dest=/tmp/bin-o'

That's a hack.  It would be better style to use a wrapper script to add the option at the end of the command line so both sides agree on the first basis dir, but I don't see that it makes any practical difference.
Comment 4 Wayne Davison 2011-11-23 21:17:55 UTC
This is not anything I ever plan to support.