I hope you dont mind, but im cc'ing the list-- ppl need to see this one of the scariest things i can imagine is a customer calling up saying the entire *monolithic* database is corrupt. the entire workday would grind to a halt and someone would have to jump through lots of hoops to just get the database (zope filesystem) back in order :(((( this is unacceptable (period) for some of the uses i had in store for Zope. is zope going to support multiple databases? jim f. said the ZODB is a SPOF -- are there any plans on fixing this? is there anyway to 'block all writes' while backing up the ZODB? w/o taking the entire website down/mostly reads anyways? is there a way you can 'scan' to see if the ZODB is intact? i.e. having a process scan the ZODB and return whether or not it is valid? what was the 'offending' transaction? thanks ~alan ----- Original Message ----- From: "M. Adam Kendall" <mak@kha0s.org> To: "alan runyan" <runyaga@thisbox.com> Sent: Sunday, February 20, 2000 1:52 AM Subject: RE: data.fs corruption
Of course, you probably aren't going to like this answer, but I spent about 4.5 hours with the Tranalyzer product, and a good hex editor hacking away at my Data.fs. The good news: I recovered all my data. The bad news: I have alot less hair now..
I basically used Tranalyzer to figure out where it blew up, and then from the comments in FileStorage.py in the Zope source I was able to figure out the file format for the Data.fs. At least I knew how many bytes record/field lengths were supposed to be. Then using the hex editor I manipulated the Data.fs until I had ripped out the offending transaction record.
Worked like a charm but was a very long drawn out process.. I would say that Digital Creations needs to provide a tool for easy data recover from corrupt Data.fs.
Adam