Re: [Zope-dev] Re: [ZODB-Dev] Big problem.
Note that untarring the attached "products" into your 2.4 Products directory should allow you to start 2.4 up with the Data.fs from your foray into 2.5 without needing to truncate anything. At that point you should be able to delete the session_data_manager, temp_folder, and browser_id_manager objects and restart without the faux products. Andrew Sydelko wrote:
Chris McDonough wrote:
Darn. At this point you can try just hacking off bits of file at the end of a *copy* of the Data.fs you have by using the trunctate method described in Itamar's howto. Start small and just cut off pieces at the end of the file until you're able to start Zope again. You might lose some data this way but at least it will start. After you get it to start, and you've lost data, you can also use (painfully slow) binary search to pinpoint where exactly you need to truncate on further copies.
I am working on preventing this on the 2.5 branch now.
It's ironic that I got on Jeremy's case for something like this not too long ago. ;-) Mea culpa.
Well, the plan for the night will be to bring the Data.fs up with 2.5.0b3 and export a critical part of the database. This part will be brought up on a separate 2.4.3 server. Then we will try to fix the problems we've been having with 2.5.0b3...
Any quick pointers on where I can find info on exporting part of the database from the command line? Either thru a ZEO client (import Zope) or some other method...
--andy.
Chris McDonough wrote:
Note that untarring the attached "products" into your 2.4 Products directory should allow you to start 2.4 up with the Data.fs from your foray into 2.5 without needing to truncate anything. At that point you should be able to delete the session_data_manager, temp_folder, and browser_id_manager objects and restart without the faux products.
Hmmm... I would have liked that to work. I get things like 404 Not found on /manage_main and /. So, I'm trying to pursue your web export external method. --andy.
Whoops, that wasn't quite enough. Also do this: Create the following Python file as "unscrew.py" in your 2_4/lib/python directory and run it. import Zope app = Zope.app() app._delObject('session_data_manager') app._delObject('browser_id_manager') app._delObject('temp_folder') del app.__before_publishing_traverse__ get_transaction().commit() Note that if you've got access rules or site roots in your root dir, this will blow those away and you'll need to recreate them. Chris McDonough wrote:
Note that untarring the attached "products" into your 2.4 Products directory should allow you to start 2.4 up with the Data.fs from your foray into 2.5 without needing to truncate anything. At that point you should be able to delete the session_data_manager, temp_folder, and browser_id_manager objects and restart without the faux products.
Andrew Sydelko wrote:
Chris McDonough wrote:
Darn. At this point you can try just hacking off bits of file at the end of a *copy* of the Data.fs you have by using the trunctate method described in Itamar's howto. Start small and just cut off pieces at the end of the file until you're able to start Zope again. You might lose some data this way but at least it will start. After you get it to start, and you've lost data, you can also use (painfully slow) binary search to pinpoint where exactly you need to truncate on further copies.
I am working on preventing this on the 2.5 branch now.
It's ironic that I got on Jeremy's case for something like this not too long ago. ;-) Mea culpa.
Well, the plan for the night will be to bring the Data.fs up with 2.5.0b3 and export a critical part of the database. This part will be brought up on a separate 2.4.3 server. Then we will try to fix the problems we've been having with 2.5.0b3...
Any quick pointers on where I can find info on exporting part of the database from the command line? Either thru a ZEO client (import Zope) or some other method...
--andy.
participants (2)
-
Andrew Sydelko -
Chris McDonough