[Top][All Lists]

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

Re: [Duplicity-talk] Behaviour/Man page of --verify and --compare-data

From: edgar . soldin
Subject: Re: [Duplicity-talk] Behaviour/Man page of --verify and --compare-data
Date: Tue, 12 Aug 2014 12:13:35 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 10.08.2014 23:59, Aaron Whitehouse wrote:
> Thanks for your response, Edgar.
>> On 21.07.2014 23:06, Aaron Whitehouse wrote:
>> We now have that new separate command (--compare-data). Consistent with
>> the various comments to date, I therefore propose that the comparison of
>> dates/modtimes is only carried out if --compare-data is used. On that
>> basis, verify would not give an error if the file-system changes after
>> the backup, so long as it can restore the files and they match the
>> signatures from the time of the backup.
> On 22/07/14 10:32, address@hidden wrote:
>> i'd rather have different commands. namely verify and compare.
> I can see the appeal in different commands, but to start with I think it
> makes sense to use the existing --compare-data option. This is easier
> because it will preserve backwards compatibility, but more importantly
> it makes sense as an option because a --compare-data is a verify plus
> more. We would want --compare-data to do everything that a normal verify
> did, plus the data comparison, so having it as an option to verify
> ensures people know that they do not need to run both.

as long as we do not have a checksum to compare a restored file against a 
verify command as such is academic anyways.

i just wanted to point out that there is a difference between them two wrt. 
their plain meaning

compare actually compare against the source
verify only verifies that the backup is not corrupted.
>>> I would also then suggest the above man page read:
>>> "Enter verify mode instead of restore. Verify tests the integrity of the
>>> backup archives at the remote location by checking each file can restore
>>> and that the restored file matches the signature of that file stored in
>>> the backup, 
>> check the source first.. duplicity surely does check the volumes
>> against a saved checksum so it won't try restoring from a corrupt
>> volume. i didn't see no comparison against a saved checksum in the
>> verify code. might be there and i just do not remember it. 
> Thanks. It would be nice if verify did check the restored file against a
> saved checksum from the time of backup, but I don't know if it does!
> Bug filed here:
> https://bugs.launchpad.net/duplicity/+bug/1354880
> where I have also posted a Bash script that steps through the current
> behaviour.

well, at least it wont be forgotten this way ;) .. development is very slow 
since a few years.. ede/duply.net

reply via email to

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