On Sep 12, 2007, at 10:28 AM, Jim Fulton wrote:
...
- checkbtrees.py
- fstest.py
There's an fsrefs script that checks internal references I believe.
fsrefs.py shows loads of problems in both the data.fs and the
resources.fs.
probably 200 entries per database. i.e.
oid 0xD87110L
On Sep 11, 2007, at 10:27 AM, Alan Runyan wrote:
And, as you said in another node, the BTree folder actually loves in
the resources database.
Correct the BTree is in /plone/resources/files to be exact.
Cross database references are inherently weak. A reference from a
foreign database
And, as you said in another node, the BTree folder actually loves in
the resources database.
Correct the BTree is in /plone/resources/files to be exact.
Cross database references are inherently weak. A reference from a
foreign database doesn't prevent an object from being treated as
Alan Runyan wrote at 2007-9-11 09:27 -0500:
...
oid 0xD87110L BTrees._OOBTree.OOBucket
last updated: 2007-09-04 14:43:37.687332, tid=0x37020D3A0CC9DCCL
refers to invalid objects:
oid ('\x00\x00\x00\x00\x00\xb0+f', None) missing: 'unknown'
oid ('\x00\x00\x00\x00\x00\xb0N\xbc',
On Sep 10, 2007, at 10:34 AM, Alan Runyan wrote:
Hi guys.
It seems that one of our customers has a corrupted BTree. I would love
for someone to provide some insight on how we can recover the data.
we have two databases: 1 for resources and 1 for 'content'. resources
contain lots of very big
Alan Runyan wrote at 2007-9-10 09:34 -0500:
...
While debugging this I had a conversation with sidnei about mounted
databases. He recalled that if your using a mounted database you
should not pack. If for some reason your mounted database had a cross
reference to another database and somehow
On Sep 10, 2007, at 10:34 AM, Alan Runyan wrote:
Hi guys.
It seems that one of our customers has a corrupted BTree. I would love
for someone to provide some insight on how we can recover the data.
we have two databases: 1 for resources and 1 for 'content'. resources
contain lots of very big
