I tried running a pack on the database via fsrecover.fs and here's
what I get:

-----
Recovering Data_fammedmain.fs into Data_fammedmain-recovery.fs
. 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 0
0 bytes removed during recovery
Packing ...
Traceback (most recent call last):
 File "/opt/Plone-2.5.2/lib/python/ZODB/fsrecover.py", line 390, in ?
   main()
 File "/opt/Plone-2.5.2/lib/python/ZODB/fsrecover.py", line 259, in main
   recover(inp, outp, verbose, partial, force, pack)
 File "/opt/Plone-2.5.2/lib/python/ZODB/fsrecover.py", line 385, in recover
   ofs.pack(pack, referencesf)
 File "/opt/Plone-2.5.2/lib/python/ZODB/FileStorage/FileStorage.py",
line 1348, in pack
   opos = p.pack()
 File "/opt/Plone-2.5.2/lib/python/ZODB/FileStorage/fspack.py", line
482, in pack
   self.gc.findReachable()
 File "/opt/Plone-2.5.2/lib/python/ZODB/FileStorage/fspack.py", line
228, in findReachable
   self.findReachableAtPacktime([z64])
 File "/opt/Plone-2.5.2/lib/python/ZODB/FileStorage/fspack.py", line
304, in findReachableAtPacktime
   todo.extend(self.findrefs(pos))
 File "/opt/Plone-2.5.2/lib/python/ZODB/FileStorage/fspack.py", line
377, in findrefs
   return referencesf(self._file.read(dh.plen))
 File "/opt/Plone-2.5.2/lib/python/ZODB/serialize.py", line 645, in referencesf
   oid = oid_loaders[reference_type](*args)
KeyError: 'n'


On 3/23/07, Laurence Rowe <[EMAIL PROTECTED]> wrote:
You need to provide the full traceback so we can tell where it is coming
from.

My guess (though I'm surprised by the particular error) is that you have
perhaps got content owned by users in a user folder outside the site
that is no longer accessible when you mount the database on its own. If
that is the case then you need to write a script to fix up the
__ac_local_roles__ on the affected objects.

Laurence

Tim Tisdall wrote:
>   Here's the thing...  I get a KeyError if that ZODB is on it's own,
> but if I create a fammed-old object that's similar to what it's
> looking for, it will then throw a POSKeyError.
>
>   The Plone instance was created fresh and then only the file
> contents of the old site were copied over to the new instance.  The
> migration of the old Plone site didn't work, but it did manage to make
> it so I could access the files contained within and copy them over.  I
> didn't copy over any stylings, products, users, widget things...  I'm
> pretty sure I just copied over AT types and a few basic zope files
> (like DTML files and zope page templates).
>
>   -Tim
>
> On 3/23/07, Christian Theune <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Can you tell whether you get a KeyError or a POSKeyError?
>>
>> If you get a KeyError, it's likely that the app (Plone) is broken, e.g.
>> during the migration you mentioned.
>>
>> A POSKeyError would (very likely) not talk about a a key like
>> 'fammed-old', so I suspect you don't have a corruption in your
>> storage/database but your application.
>>
>> Christian
>>
>> Am Freitag, den 23.03.2007, 12:04 -0400 schrieb Tim Tisdall:
>> >   I've got a 1gb ZODB that contains a single plone site and I'm not
>> > able to access any part of it via the ZMI.  It keeps saying that it's
>> > looking for key "fammed-old" which is another plone site in another
>> > ZODB file.  Basically I managed to partly migrate a Plone 2.0 to Plone
>> > 2.5 and then copied over the file contents from that instance into a
>> > new Plone instance.  I have no idea why the new one would be
>> > referencing the old one, but it seemed to always throw this error if
>> > the old database was unmounted.
>> >   I've tried several "cookbook" fixes I've found, but the problem is
>> > that the plone instance itself is throwing the KeyError.  Deleting the
>> > whole plone instance is not going to help me much.  Any suggestions?
>> >   I've also tried running the fsrecovery.py, but it simply makes a
>> > complete duplicate of the file.  fstest.py doesn't seem to find any
>> > errors.  fsrefs.py finds a series of errors, but I have no idea what
>> > to do with that information.  It seems that it's finding that it's
>> > referencing "fammed-old" and that that doesn't exist.
>> >
>> >   -Tim
>> > _______________________________________________
>> > For more information about ZODB, see the ZODB Wiki:
>> > http://www.zope.org/Wikis/ZODB/
>> >
>> > ZODB-Dev mailing list  -  ZODB-Dev@zope.org
>> > http://mail.zope.org/mailman/listinfo/zodb-dev
>> --
>> gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
>> www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
>> fax +49 345 122 9889 1 - zope and plone consulting and development
>>
>>
> _______________________________________________
> For more information about ZODB, see the ZODB Wiki:
> http://www.zope.org/Wikis/ZODB/
>
> ZODB-Dev mailing list  -  ZODB-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zodb-dev
>

_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

Reply via email to