|Subject:||Re: [Duplicity-talk] Incremental backup of files with changed data but unchanged timestamp|
|Date:||Sun, 3 Aug 2014 06:05:26 -0500|
On 03.08.2014 02:03, Nate Eldredge wrote: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..
> 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.
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
i cannot seem to find a routine that checks time stamps before that.
@Ken, Mike: can you hint where this magic happens?
|[Prev in Thread]||Current Thread||[Next in Thread]|