verify command does not penetrate cache/archive
Bug #601660 reported by
Peter Schuller
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Duplicity |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Running "duplicity verify URL dest" should never use any data from the persistent cache/archive that would otherwise be obtained from the remote backup, as the purpose of running the command is to verify the correctness of the backup data independently of any locally stored information.
The test I ran to conclude that this was a problem was:
(1) duplicity src file://./dest
(2) Modify a manifest file in ~/.cache to contain the wrong hash.
(3) still succeeds: duplicity verify file://./dest src
Indeed, testing actual server-side corruption confirms it:
(1) duplicity src file://./dest
(2) Modify a random byte in a manifest file in dest
(3) still succeeds: duplicity verify file://./dest src
Changed in duplicity: | |
status: | New → Fix Released |
To post a comment you must log in.
Peter,
Is there any chance you could please re-test this on the trunk, as I suspect it has been fixed?
The tests that I added in: /code.launchpad .net/~hooloovoo /duplicity/ add-additional- verify- tests-for- corrupted- archives
https:/
(now merged) were designed to corrupt the destination archives, rather than the cache, and these tests are passing as expected.
In your description above, did you mean:
"Modify a manifest file in dest to contain the wrong hash." rather than
"Modify a manifest file in ~/.cache to contain the wrong hash"?
As I understand it, you are saying that the cache should be ignored in any verify, so changing the cache shouldn't stop the verify succeeding.