On 30.08.2011 21:24, Eliot Moss wrote:
> On 8/30/2011 1:11 PM,
address@hidden wrote:
>
>>> What some respondents are not realizing (because I probably did not
>>> make it clear), I am not necessarily talking about the case where
>>> duplicity is run a second (or third, or whatever) time, but when the
>>> rsync backend has a network problem and tries to send the *same*
>>> volume file again.
>>
>> crystal clear to me.
>>
>>> --partial would be very reasonable in such a case.
>>
>> Not all backends support resuming in protocol so it might proof more complex to implement.... Ede /
duply.net
>
> Hmmm ... at present it retries the rsync command some
> number of times before failing out of duplicity. I am
> only suggesting that the rsync back end be set up to
> use rsync's --partial feature, merely because it is there
> and would work transparently to help file transfer
> retry for that back end. I agree that with the diversity
> of back ends, there is probably not a general solution
> to saving a partial transmission when retrying the
> transmission of a volume. (Some ftp's can restart,
> but rsync has the capability to check that the already
> transmitted bytes are the same (or similar) and to reuse
> what was there before, in rsync's normal way of comparing
> source and destination.)
>
> So I don't think this is at all hard to implement. All that
> is required is to add this to the rsync command line:
>
> --partial-dir=.rsync-partial
>
> Best wishes -- Eliot