Useful for the interim case of ZODB 3.2 and Zope 2.6, where you want
to load from a config file in custom_zodb.py.

When a corrupted record is found, it guesses a location for the next
good transaction header.  If the guessed location happened to have a
'c' character at just the right spot, it would think it was at the end
of the file.

Fix in off-by-one bug in scan() that lead to failure.

Do more sanity checks for invalid transaction headers following a
scan.

Use restore() instead of store() to copy data.  This change should
maximize the chance that the recovered storage is identical except for
the damaged records.

Add tests from the trunk and remove test in testFileStorage.

threads that lead to unreported test failures.

is accessed. This improves some odd unsliceable object TypeErrors which
popped up from inside fsIndex.

happy again.

Reported by Sidnei da Silva.

information to ReadConflictError

(Just hope that the storage is sane :-).

The pack() implementation would leave a corrupted storage behind if
transactions committed while packing.

merge toby_directorystorage_tests_branch. Inhibit tests that use versions when not supported by the storage. Allow a subclass to insert a pause between consecutive packs if needed. DirectoryStorage now passes all the ZODB tests.

for the common case and reducing the impact of any memory leaks associated
with sys._getframe().

Only expose the items attribute of the special dict inside the cache.
Exposing other methods that mutate the dict is dangerous, because of
the ref count games the cache plays.

2.1.

from a dict with a float value.

Mapping_update():  This squashed errors raised by PyObject_SetItem(),
changing them to a "not a 2-tuple" TypeError instead.  Unclear why, since
2-tupleness was checked earlier.  Fixed by backporting part of the
ZODB4 BTree construction code, which doesn't have this problem.  Bonus:
it's faster now too.

ZODB4.

due to the coarseness of time.time() on Windows.  It looks like an
attempt was made before to fix this, and also removed a wrong comment
explaining that fix.  .pack() used to be documented incorrectly, saying
that stuff before the pack time was packed away.  It's actually the case
that stuff before *or equal to* the pack time is packed away, and that's
a crucial distinction on Windows because time.time() often (usually,
in fact) returns the same value on two successive calls.  The earlier
fix attempt tried to separate observed time.time() values, but did so
before the pack().  That's usually appropriate, but in this test we
really need to make sure that object revisions *after* the pack() get
timestamps distinct from the pack time (else they'll get packed away,
and the test isn't expecting that).

a MappingStorage (which doesn't support versions), so stop trying to
test that combo.

Reduces memory usage during pack by a considerable fraction with
modest 10% slowdown.

We're still missing tests that cover important cases.  Unexecuted code
below:

>>>>>>             if l > len(data) - 8:
>>>>>>                 pos += l
>>>>>>                 break
>>>>>>             s = l + 1
>>>>>>             tl = u64(data[s:s+8])
>>>>>>             if tl < pos:
>>>>>>                 return pos + s + 8

>>>>>>         except:
>>>>>>             if partial and nrec:
>>>>>>                 ofs._status = 'p'
>>>>>>                 ofs.tpc_vote(transaction)
>>>>>>                 ofs.tpc_finish(transaction)
>>>>>>                 if verbose:
>>>>>>                     print 'partial'
                   else:
>>>>>>                 ofs.tpc_abort(transaction)
>>>>>>             print "\n%s: %s\n" % sys.exc_info()[:2]
>>>>>>             if not verbose:
>>>>>>                 progress(prog1)
>>>>>>             pos = scan(file, pos)

Add main() function to do argument processing separate from recover().

version, and likely won't be again.