Yup, by doing --inplace, I got down from 30 mins to 24 mins... So that's
slightly better than resending the whole file again.
However, this doesn't really do what I was hoping to do. Perhaps it can't
be done, or somebody would like to recommend some other product that is more
well suited for m
ehar...@lyricsemiconductors.com wrote:
I thought rsync, would calculate checksums of large files that have
changed timestamps or filesizes, and send only the chunks which
changed. Is this not correct? My goal is to come up with a
reasonable (fast and efficient) way for me to daily increment
Matthias Schniedermeyer (m...@citd.de) wrote on 5 September 2009 00:34:
>On 04.09.2009 18:00, ehar...@lyricsemiconductors.com wrote:
>>
>> Why does it take longer the 3rd time I run it? Shouldn?t the performance
>> always be **at least** as good as the initial sync?
>
>Not per se.
>
>Firs
On 04.09.2009 18:00, ehar...@lyricsemiconductors.com wrote:
>
> Why does it take longer the 3rd time I run it? Shouldn?t the performance
> always be **at least** as good as the initial sync?
Not per se.
First you have to determine THAT the file has changed, then the file is
synced if there was
