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

[Aaron Whitehouse]

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.

>>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.

Regards,

Aaron