[Top][All Lists]

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

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

From: edgar . soldin
Subject: Re: [Duplicity-talk] Incremental backup of files with changed data but unchanged timestamp
Date: Sun, 03 Aug 2014 13:39:20 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

hmm, some more searching didn't reveal no options for the librsync create delta 
call. it simply seems to create signatures for the whole file only.

that suggests that the mtime is compared somewhere else, probably in
although i am absolutely clueless as to where in the code path this is supposed 
to happen.

@Ken, Mike: any (more) input?

after all this (identical mtime) comes up from time to time on the list e.g.
rsync allows to enforce checksum checking '-c' as well, so people probably will 
expect this from duplicity. 


On 03.08.2014 13:05, Kenneth Loafman wrote:
> I've seen packages that have the timestamp reflect the version number, so
> he's probably right, it would be the packager doing the dirty trick.
> I'm fairly sure you are right that DeltaFile is the first place.  I could
> not find anything else.  Mod that and he should be good to go.  It will be
> a lot slower, so save the original for the next backup.
> ...Ken
> On Sun, Aug 3, 2014 at 5:11 AM, <address@hidden> wrote:
>> 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

reply via email to

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