duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] checksum rsync option (duplicity 0.6.21)


From: edgar . soldin
Subject: Re: [Duplicity-talk] checksum rsync option (duplicity 0.6.21)
Date: Mon, 22 Jul 2013 17:56:24 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7

hmmm.. you could check their documentation. probably they've got a good reason, 
although it makes no sense to activate it by default. maybe it is similar to 
photgraphy, where photographs want keep the time stamps after editing meta data?

..regards ede/duply.net

On 22.07.2013 17:11, Laurent Lavaud wrote:
> ok thanks for the explanations, i can remove my useless rsync option !
> 
> and i have found the guilty option in my tag tool (puddletag), "preserve file 
> modification time", it is weird to add an option like this...
> 
> 
> --
> Laurent Lavaud
> Administrateur Systèmes et Réseaux
> 
> ----- Mail original -----
>> On 22.07.2013 14:23, Laurent Lavaud wrote:
>>> Hello,
>>>
>>> I would like to use the rsync checksum method to detect files
>>> modification because the "classic" method do not detect some
>>> changes, like mp3 tag modification (mtime not modified)
>>>
>>> So i have tried to add --rsync-options="--checksum" to my duplicity
>>> command line:
>>>
>>> /usr/bin/duplicity -v9 --encrypt-key=xxx --sign-key=xxx --use-agent
>>> --allow-source-mismatch --rsync-options="--checksum" test
>>> ssh://address@hidden/backup/test
>>>
>>> But duplicity doesnt seem to use it because it not detect the file
>>> modification...
>>>
>>
>>
>> --rsync-options only applies to the rsync backend. the internal
>> librsync routine is not configurable. actually duplicity itself
>> decides if the file changed and invokes librsync internally then.
>>
>> duplicity compares wrt. time only mtime
>>  
>> http://bazaar.launchpad.net/~duplicity-team/duplicity/0.6-series/view/head:/duplicity/path.py#L306
>> for performance reasons.
>>
>> only verify can compare data as well. this is a design decision.
>> duplicity backup data is usually stored remotely. comparing data
>> during backup would need to restore the former version of the file
>> locally and therefor download all volumes necessary resulting in
>> lot's of traffic.
>>
>> what i describe above is merely the status quo. i am aware that in
>> theory a checksum could be saved remotely but i cannot find anything
>> like that in duplicity's source. the tarfile info used as metadata
>> store also does not seem to support an entry like that.
>>
>> Ken, Mike: is the above correct?
>>
>> Laurent: wrt. your issue above. the behaviour of your tagging
>> software or filesystem is the "real" problem here. usually
>> filesystems modify mtime automatically on every write access. if
>> not, something weird is going on and you should research what's
>> going on there. e.g. we had users on the list where mounted remote
>> filesystems did not update file stat data correctly.
>>
>> good luck ..ede/duply.net
>>
>>
>>
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]