|
From: | Kenneth Loafman |
Subject: | Re: [Duplicity-talk] Incremental backup of files with changed data but unchanged timestamp |
Date: | Sun, 3 Aug 2014 07:31:18 -0500 |
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.
http://librsync.sourcefrog.net/doc/librsync.html#processing-whole-files
that suggests that the mtime is compared somewhere else, probably in
http://bazaar.launchpad.net/~duplicity-team/duplicity/0.7-series/view/head:/duplicity/path.py
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.
https://lists.nongnu.org/archive/html/duplicity-talk/2013-07/msg00015.html
rsync allows to enforce checksum checking '-c' as well, so people probably will expect this from duplicity.
..ede
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
>>
>
[Prev in Thread] | Current Thread | [Next in Thread] |