zopefoundation / ZODB / 14421359493 / 1

84%

master: 84%

push

github

FileStorage: Fix restore to correctly check restored data content (#409)

In commit 8160568b (FileStorage: fix rare data corruption when using
restore after multiple undos (#395)) we fixed FileStorage.restore to
work correctly in the presence of multiple undos for the same oid in the
same transaction by reworking oid data records of one transaction to be
all scanned in the loop. But unfortunately that commit introduced a
regression:

When restore is instructed to do an undo, in other words, to make a copy
of oid data by referring to that data by backpointer, it checks content
of the pointed-to record, and if data content there does not match data
content passed to restore call, the copy-via-backpointer optimization is
silently disabled. However 8160568b contained a thinko when doing the
check: after discovering pointed-to oid data record, the intent there it
was to load actual data from there, but the loading was performed not
from the offset where the data lives, but from then beginning of some
next data-record header instead. As the result the
"copy-via-backpointer" was always disabled.

-> Fix that by seeking to correct position before loading the data.

I originally discovered this issue by running Zodbtools tests wrt ZODB6
and getting failures for `zodb restore` related tests with difference in
between restored and expected states as e.g.

    @@ -296,15 +296,21 @@
     txn 0285cbad77777800 " "
     user "root1.0\nYour\nMagesty "
     description "undo 1.0\nmore detailed description\n\nzzz ...\t"
     extension ""
    -obj 0000000000000005 from 0285cbad6962fd19
    +obj 0000000000000005 30 sha1:5fe26f631
    +c__main__
    +Object
    +q^A.U^Ea1.22q^B.

/cc @d-maurer
/reviewed-by @perrinjerome
/reviewed-on https://github.com/zopefoundation/ZODB/pull/409

2439 of 3540 branches covered (68.9%)

13338 of 15912 relevant lines covered (83.82%)

0.84 hits per line