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

[Dieter Maurer]

Chris Withers wrote at 2005-1-27 23:05 +0000:
>Has anyone else here noticed that with Zope 2.7.x and 
>LocalFS-1-3-andreas, when FS-based objects are changes through LocalFS, 
>changes are also stored to the ZODB (you'll see a transaction for any 
>change made in the Undo tab of the root of your Zope instance) as well?
>
>The changes are made up as follows (from fsdump.py):
>
>   data #00000 oid=000000000000727e class=OFS.Image.Pdata
>   data #00001 oid=000000000000727f class=OFS.Image.Pdata
>   data #00002 oid=000000000000727c class=OFS.Image.Pdata
>   data #00003 oid=000000000000727d class=OFS.Image.Pdata
>   data #00004 oid=000000000000727b class=OFS.Image.Pdata
>   data #00005 oid=0000000000007282 class=OFS.Image.Pdata
>   data #00006 oid=0000000000007283 
>class=Products.LocalFS.LocalFS.ObjectWrapper
>
>   data #00007 oid=0000000000007280 class=OFS.Image.Pdata
>   data #00008 oid=0000000000007281 class=OFS.Image.Pdata
>
>...and packing removes them.

This is funny indeed.

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.


Did you show us a complete transaction?
Or are more objects involved?

>Does anyone know what's causing this and what could be done to fix it?

Debugging in an interactive Python session?

-- 
Dieter