[Zope] Question about possible Data.fs corruption

[Ira Sher]

Dieter,
Thank you for your responses. I've determined from the catalog that the 
forty-odd records with path problems generally have a double-backslash 
at the beginning, and otherwise contain the correct path. I'm going to 
try to update them.

The objects (like the one I originally enquired about) that were 
causing such problems with the site have been removed, but when 
re-added, while I think I've solved the condition that was causing the 
path to appear incorrectly, I have noticed that these objects don't 
otherwise behave as expected (and cause problems on the live site) 
because where scripts look for the following data:
<dtml-in "Catalog.searchResults(meta_type='Book',sie='on')">
and the dtml script writing the data is writing:
<dtml-call "REQUEST.set('id','readers_guide')">
<dtml-call "REQUEST.set('sie','on')">
<dtml-with "Readers_Guide.createInObjectManager(REQUEST['id'], 
REQUEST)">
  <dtml-call "propertysheets.Basic.manage_editProperties(REQUEST)">
  <dtml-call 
"aq_parent.propertysheets.Basic.manage_changeProperties(REQUEST)">
  <dtml-call "reindex_object()">
  <dtml-call "aq_parent.reindex_object()">
</dtml-with>
which would seem to set sie as "on", the newer records return sie as 
True rather than "on", and so fail. The version of python was updated 
on the live server. Could this have caused the problem? How can I be 
more explicit in the call to ensure that "on" is preserved rather than 
converted to True?
thanks again
ira

On Mar 6, 2004, at 3:27 PM, Dieter Maurer wrote:

> Ira Sher wrote at 2004-3-5 18:02 -0500:
>> This is the traceback I always get from adding this particular object
>> and then going to view the site homepage:
>> ...
>>    - __traceback_info__: data_record_id_
>>   Module <string>, line 1, in <expression>
>>   Module Products.ZCatalog.ZCatalog, line 562, in getobject
>>   Module OFS.Traversable, line 106, in unrestrictedTraverse
>>    - __traceback_info__: (['105586758764', 'Neela Vaswani', 
>> 'Authors'],
>> '')
>> IndexError: string index out of range
>>
>> Based on feedback I've been getting here, I'm definitely not
>> concentrating on data corruption anymore...any ideas about where best
>> to place my attentions?
>
> One of your objects (the one your application currently tries to
> access) is catalogued with a bad "uid" (unique id).
> Usually, the "uid" is a path derived from "getPhysicalPath" (the path
> from the root to the object).
> In the case of this object, the uid is a path
> "...//Authors/Neela Vaswani/105586758764" but the path contains
> an empty segment. "unrestrictedTraverse" (called by "getObject")
> cannot handle this case.
>
>
> We can fix this manually when you have enough information
> to identify the object.
> For this, you must determine the path with the empty
> segment. For this, you would replace the "getObject" by a
> "getPath" and output the path somehow.
> Then, in a Python Script (or interactively, when you know
> how you do this) you call "...catalog.uncatalog_object(yourBadPath)".
> This removes the broken object from the catalog.
> After that, you recatalog the object again
> "...catalog.catalog_object(yourObject)".
>
> Of course, we then still do not know how the bad path happened
> to enter the catalog. Other objects might suffer from the
> same problem....
>
> -- 
> Dieter
>