[Zope] LocalFS-1-3-andreas and Zope 2.7.2

[Chris Withers]

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