There's a persistent rumor on the spambayes mailing list that dumbdbm
databases are associated with corruption problems, so I studied this code
carefully and ran some brutal stress tests. I didn't find any bugs,
although it's unclear whether this code *intends* that __setitem__ can
leave the directory file out of synch with the data file (so
if a dumbdbm isn't properly closed, and the value of an existing key
was ever replaced, corruption is almost certain, where "corruption"
means the directory file is out of synch with the data file).
Added many comments and generally modernized the code. Examples of the
latter: we have better ways of reading a whole file line-by-line now;
eval() now tolerates a trailing newline; the %r format code can be used
to avoid explicit repr/backtick calls; and the code often broke tuples
into their components when it was clearer and faster to just leave them
as tuples.
1 file changed