Re: [Duplicity-talk] Incremental backup of files with changed data but unchanged timestamp

[edgar . soldin]

On 03.08.2014 02:03, Nate Eldredge wrote:
> I am using duplicity to make incremental backups of my system.  I have some 
> files whose data has changed since the last backup, but whose mtime stayed 
> the same.  It looks like `duplicity incremental' ignores files whose 
> timestamp has not changed, so it doesn't back up the new data.  Is there a 
> way to force duplicity to compare the file with a stored checksum, or even to 
> use rdiff unconditionally?  I'd prefer not to have to do a new full backup.
> 
> I'd consider hacking duplicity myself but it would be helpful to know where 
> in the code I should look.
> 
> (Before you accuse me of abusing timestamps: it isn't my fault!  I 
> crossgraded this Ubuntu system from 32-bit to 64-bit.  It appears that some 
> Ubuntu packages have the same timestamps on corresponding files in the 32-bit 
> and 64-bit versions.  Presumably the packages were generated at the same 
> time, and coincidentally those files were compiled during the same second.  
> So when I replaced the 32-bit package with the 64-bit package, I get a 
> different file with the same timestamp.)
> 
> I'm using duplicity 0.6.23 (latest from the PPA) on Ubuntu 14.04.
> 

i like "(Before you accuse me of abusing timestamps: it isn't my fault!" bit .. 
hehe as long as the time stamps were old enough you will get off scott free i 
guess..

but seriously - this was obviously not on the horizon of when duplicity was 
developed. i searched a bit but couldn't find anything apart from the librsync 
call 'librsync.DeltaFile(old_sigfp, newfp)' in
 
http://bazaar.launchpad.net/~duplicity-team/duplicity/0.7-series/view/head:/duplicity/diffdir.py#L136

i cannot seem to find a routine that checks time stamps before that.

@Ken, Mike: can you hint where this magic happens?

..ede