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

[edgar . soldin]

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