that is cleaned up at the start of a test run.

Unfortunately, the ZODB tests leave lots of temporary files behind
which can cause failures in subsequent test runs and which tend to
litter /tmp. Eventually, I want to clean that up, but, in the mean
time, I can limit the damage to the test part directory.

windows. The test author asures me that leaving the handle open wasn't
intentional.

Follow-up to r91064 to also allow deep-copied blobs to be opened (also see http://mail.zope.org/pipermail/zodb-dev/2008-August/012054.html).

  correctly, leaving the client storage in an inconsistent state.

the file storage is closed because it's internal meta data may be
invalid.

1. The saving was performed in (tpc)_finish.  It is important that this
   method do as little as possible because it cannot fail!

2. The algorithm for deciding how often to save was broken. For large
   databases, for which saving periodically is desireable, the period
   was set so high that the index was effectively never saved.

It might be nice to save periodically, but doing so is tricky, since
we really don't want to do it during commit.  Until we figure out how
to do this right, it is better not to try.

In the mean time, we save on close and on pack, which is proably often
enough in most cases.

Windows. :/

have not been initialized (as can happen when doing a deep copy of a
blob object)

a possible ordering problem for invalidation messages.

This was motivated by code inspecition during merge of an earlier
refactoring to the trunk.  The refactoring also simplifies the code
and probably makes it a tad faster.

  with the data in a way that prevents data from being loaded into the
  cache. We don't yet know why, but added an exception handler to
  prevent this error from being fatal.

written on.

for large databases on systems that don't allow many subdirectories.

an out-of-date server.

servers with zeo clients to be delayed.

  of a Python disctionary for a mapping that can grow large.

(Not large enough to use a lot of memory, but large enough to cause
  malloc to fail. :()

for objects that were explicitly added to a database if the object
was modified after a savepoint that added the object.