A quick and dirty workaround might be to remove the mtime check altogether. Then it will treat every file as if it has changed, and backup the changes since the last run (using the rdiff algorithm as usual). For files whose data has not actually changed, this will be a small amount of data; if you don't have a huge number of files it might be tolerable. It will also make restoring less efficient as it applies lots of trivial diffs. But if you have to deal with files whose data may change without updating the mtime, it might be better than nothing.
Perhaps this would be useful to have as an option (--ignore-time or similar).
-------- Original message -------- From: Laurent Lavaud <address@hidden> Date: 07/22/2013 11:11 (GMT-05:00) To: Discussion of the backup program duplicity <address@hidden> Subject: Re: [Duplicity-talk] checksum rsync option (duplicity 0.6.21)
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