One of the programmers here managed to corrupt a Durus database in a
novel way.  On opening the FileStorage, the _build_index() method dies
with the following exception:

Traceback (most recent call last):
  File "t.py", line 4, in ?
    fs = file_storage.FileStorage('bad.models.durus')
  File "/usr/lib/python2.3/site-packages/durus/file_storage.py", line 107, in
__init__
    self._build_index()
  File "/usr/lib/python2.3/site-packages/durus/file_storage.py", line 139, in
_build_index
    raise ValueError("Object OID %r duplicated" % oid)
ValueError: Object OID '\x00\x00\x00\x00\x00\x01Z\x03' duplicated

(I added a %r to the 'raise' statement to display the OID.)  Adding a
debugging printout of transaction ID and OID provides some more
detail:

'\x00\x00\x00\x00\x00\x00Cu' '\x00\x00\x00\x00\x00\x01R{'
'\x00\x00\x00\x00\x00\x00Cu' '\x00\x00\x00\x00\x00\x01Rz'
'\x00\x00\x00\x00\x00\x00Cu' '\x00\x00\x00\x00\x00\x01Ry'
'\x00\x00\x00\x00\x00\x00Cu' '\x00\x00\x00\x00\x00\x01Rx'
 ...
'\x00\x00\x00\x00\x00\x00Cu' '\x00\x00\x00\x00\x00\x01Z\x0e'
'\x00\x00\x00\x00\x00\x00Cu' '\x00\x00\x00\x00\x00\x01Z\x03'  << first
occurrence of ID
'\x00\x00\x00\x00\x00\x00Cu' '\x00\x00\x00\x00\x00\x01Z\x02'
'\x00\x00\x00\x00\x00\x00Cu' '\x00\x00\x00\x00\x00\x01Z\x01'
'\x00\x00\x00\x00\x00\x00Cu' '\x00\x00\x00\x00\x00\x01Z\x00'

 ...
'\x00\x00\x00\x00\x00\x00Cu' '\x00\x00\x00\x00\x00\x01X\x07'
'\x00\x00\x00\x00\x00\x00Cu' '\x00\x00\x00\x00\x00\x01VG'
'\x00\x00\x00\x00\x00\x00Cu' '\x00\x00\x00\x00\x00\x01Z\x03'  << duplicate ID

The database in question doesn't have any valuable information, so we
could just delete it and start from scratch.  It's also possible that
this is due to a Reiserfs problem; I've noticed that crashes will
occasionally cause blocks from one file to appear in another; perhaps
a chunk of one transaction got duplicated like this.  On the other
hand, maybe this is a symptom of a Durus bug.  Should this problem be
analyzed further, or should I just delete the bad FileStorage and get
on with life?

--amk