To the best of my knowledge I did not pack at any time since the creation of this Version before my first save attempt. It's been three weeks so I'm not 100% sure though. However, google searches turned up a couple of comments indicating that packing might help this problem and so since the initial failure I have packed the database hoping that would help. It did not. Rightly or wrongly this is what I did. At this point I am manually importing and exporting each folder and loose object and importing them into a clean Data.fs. This is tedious and is going to take hours but I guess I will have learned my lesson about Versions. I'm still open to easy fixes if anyone comes up with anything, but I'll toil along with this long version workaround until I hear otherwise. Thanks, Ken On Tue, 2003-05-20 at 16:07, Troy Farrell wrote:

Ken, did you pack your ZODB before you try to save or discard the version? If so, I fear that you may have been bitten by this ZODB packing bug. Your best shot atm may be to restore from backups...

If you did not, I don't really know what's wrong...

Troy

Troy Farrell wrote:

What's bothersome is how it is not working. If versions are really a problem, they should be removed until they work and are not causing data loss. We shouldn't say that Zope can do versionning, but don't use it because you might loose data. Perhaps one of the versions gurus has some insight for us.

IANVG, but I can tell you that versions as implemented in zope (2.3.3) are evil. They are totally uncontrollable by permissions, since they just depend on the client sending a certain cookie, without even checking if the corespondending Version object even exists (text book example for the violation of the "never trust the client" principle). At least it was this way in 2.3.3, and I doubt anything has changed since then. Therefore, even if that database corruption bug is fixed, I'd like to see at least the possibility to completly turn off the version _functionality_ (i.e. said cookie is ignored instead of causing an change of an object getting versioned). cheers, oliver

On Wed, 2003-05-21 at 13:55, Dieter Maurer wrote:

Ken Causey wrote at 2003-5-20 15:27 -0500:

...

... I have a Version I've been working in now for about 3 weeks. I've modified and/or created around 50 new objects. No matter what I do I can neither Save or Discard this version.

Can you please describe precisely, what happens when you try to "save" or "discard" the version.

You get what exceptions (type, value, traceback) or what behaviour (precise description).

Sometimes, the "Version management" in "Control_Panel" can do more than the version objects themselves.

I tried it both ways. What happened was exactly nothing. No error messages or tracebacks. As far as I could tell (when saving) the 'primary' of each object was unchanged. In other words any changes made in the version were not applied, this includes not seeing any object I had added. And in either case (saving or discarding) the locks were not released on any object which I had modified. I believe at some point I even had all the details and stupid logging enabled and didn't get any errors there either.

...

... I've packed the database two or three times.

If you still have a backup from your "Data.fs" before the first pack, keep it.

Since I packed 2 or 3 times in an attempt to get it working I'm certain it was overwritten. I could dig a copy off of a backup tape. But at this point I've built a brand new Data.fs using the import/export process (had to do each root object manually) and everything is working fine. The bad taste disinclines me from touching Versions for a while.

Versions are implemented by backpointers. Under some conditions (not too often), "pack" may loose objects referenced by backpointers.

This is probably not your problem.

...

I'm using Zope 2.6.1 with Python 2.1.3. If there is any other information I can provide please let me know.

The standard one ;-) See above.

Thanks, I hope the little information I can provide helps. Ken

Dieter