Dieter Maurer wrote:
...and packing removes them.
This is funny indeed.
I think that depends on whether you're maintaining the Zope server that has 1.5GB of disk space eaten up by junk ;-)
When a transaction contains an object's data, then this means that either
* this object was modified
* this object was new *AND* is referenced by a modified persistent object
* this object explicitely was assigned a "_p_oid" and was later modified
In the first and second case, one would expect that the object is still reachable after the transaction. Thus packing should not remove it.
It is highly unlikely, that LocalFS assigns oids explicitly. Thus, three should not apply.
Yes, but remember what LocalFS is doing is trying to spoof Zope into believing objects come from within the ZODB, while actually storing them on the file system. I have a hunch that it probably mixes OFS.Image.File into its "File" objects, and OFS.Image.File is doing something naughty (it usually does, it's got some VERY esoteric code in it ;-) which results in data being comitted to the ZODB. However, since LocalFS manages to not store any data in the ZODB, the stuff OFS.Image.File causes to get comitted probably gets packed away... Sound plausible? I'm still keen to hear of anyone else who can reproduce this...
Did you show us a complete transaction?
Yep, pretty sure I did.
Or are more objects involved?
Nope. All data in this project is supposed to be stored either in Oracle or on the file system (accessed through LocalFS).
Does anyone know what's causing this and what could be done to fix it?
Debugging in an interactive Python session?
Okay, but what am I looking for? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk