With complimentary automated functional test cases and a README at https://github.com/mgedmin/repozo-testcases
Bug #1: insufficient error detection.
You can truncate a *.deltafs in the middle, and repozo -R doesn't notice
-- it goes on to produce a corrupt Data.fs.
AFAIU the *.dat file contains enough information to do basic sanity
checking for the sizes of the various *.deltafs files. It'd be nice if
repozo -R noticed and aborted with a loud complaint when one of the
files is truncated. Checksum checking would be even nicer, but,
perhaps, expensive, and so maybe ought to require an extra command line
option to enable.
To reproduce:
git clone git://github.com/mgedmin/repozo-testcases.git
cd repozo-testcases
make test2
Bug #2: two frequent runs of repozo -B may cause repozo -R to silently
produce a corrupt Data.fs.
Discovered while I was writing the above test case. If there's a
timestamp collision between the original .fs and the first .deltafs,
repozo -R produces a truncated Data.fs. (If there's a timestamp
collision between two .deltafs files, repozo -B aborts with an error,
which is fine by me.)
To reproduce:
git clone git://github.com/mgedmin/repozo-testcases.git
cd repozo-testcases
make test1
I've found the first bug in ZODB3 3.9.7, and reproduced both with the
latest ZODB3 3.10.5.
I'm not opposed to spending some time working on this, if somebody can
provide some hand-holding on IRC (I've motivation issues due to burnout).
Hm, this email is probably more descriptive than the README.txt.
Marius Gedminas
--
The clothes have no emperor.
-- C.A.R. Hoare, commenting on ADA.
signature.asc
Description: Digital signature
_______________________________________________ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
