Comment 11 for bug 631275

On 16.11.2010 00:40, az wrote:
> On Sat, 13 Nov 2010 16:41:32 GMT, edso writes:
>> check your machines for different rsync versions. For me rsync 3.0.4 and
>> 3.0.7 behave differently with an existing RSYNC_RSH entry.
>
> thanks for the hunting down of this issue.
>
> as far as i can see from the rsync docs, the src/dest args that
> duplicity feeds it was never expected to work: for rsync-daemon access
> it's either ':: after hostname but no rsync://' or
> 'rsync:// but then a / after hostname'. i assume that they've tightened
> their uri handling between 3.0.4 and .7.

You are right man page states
"you either use a double colon :: instead of a single colon to separate the hostname from the path, or you use an rsync:// URL."

Who would have guessed that.

Just for my backlog please, what are your rsync versions?

>
>> 3.0.4 ignores on rsync://url
>> 3.0.7 tries to use it on the same url
>
> i've just experimented a bit further, and rsync-daemon with 3.0.7
> works fine (regardless of RSYNC_RSH) iff you run it like
> rsync otheruser@othermachine::modulename/furtherdirs/
> or
> rsync rsync://otheruser@othermachine/modulename/furtherdirs/

that's obviously because rsyncbackend uses the "erroneous" syntax
rsync://otherbox::/module/somedir/

>
>> a) unset the variable
>
> this doesn't work: duplicity still fails with rsync 3.0.7 when an rsync-daemon
> url is used.
>

ould you please try to replace the line

self.url_string = "rsync://%s::/%s" % (host, path.lstrip('/:'))

in rsyncbackend.py with

self.url_string = "%s::%s" % (host, path.lstrip(':'))

and check if that works?

thanks ede/duply.net