id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
1269,osync_format_env_find_path_formats_with_detectors triggering LOTS of conversions,Graham Cobb,dgollub,"I am syncing between GPE and file.  GPE supports (among other things) vevent20 and the events received from the device are handed to the engine in vevent20 format.

Then it gets weird.  These events are going to file and so really only need a null conversion, to plain.  However, the log shows the event being converted many times including to xmlformat, and the xmlformat being converted to vevent20 and vevent10 and then, later, the vevent10 gets converted to xmlformat again and that (new) xmlformat triggers bug #1268 and the sync aborts.

I have never understood the code which decides which format conversions are necessary but it seems to be particularly confused in this case.

Unfortunately, the log I have showing this is very large.  However, I can provide an extract if required.  The overall logic from the log seems to be something like...

{{{
The engine receives the change in vevent20 format: Dispatching 0x2131420:10(OSYNC_MESSAGE_NEW_CHANGE), timeout=0, id=0
Received change gpe-event-920, changetype 1, format vevent20, objtype event from member 2

The engine decides to convert the event to xmlformat-event: converting to format xmlformat-event

That works OK and the OSYNC_MESSAGE_NEW_CHANGE processing is completed.
}}}
Later...
{{{
The engine receives a MULTIPLY command: osync_obj_engine_command(0x212f500:todo, MULTIPLY, 0x7fd0b1da1ca8)

I'm not sure why it says ""todo"" in that line -- this is not a todo.  Does that mean anything?

The multiply happens: Multiplying 1 mappings
Orig change type: 0 New change type: 1

Then, still within the handling of the MULTIPLIED event, the engine dispatches a PREPARE_WRITE event:
osync_obj_engine_command(0x212cc10:event, PREPARE_WRITE, 0x7fd0b1da1a50)
Starting to convert change(0x33b3d50:gpe-event-920)/entry(uid:gpe-event-920/id:0) from objtype event and format xmlformat-event

It then calls: osync_format_env_find_path_formats_with_detectors(0x1bae5f0, 0x33a0080, 0x33aef80:file, , 0x7fd0b1da1a50)
which never returns until after causing lots of conversions including the error 
in bug #1268
}}}

Even if the error hadn't caused the abort, would this have ever finished?  It seems a lot of work to do for one change.  Is the resulting path cached or will this be repeated for each event (of which I have thousands)?",defect,new,normal,OpenSync 0.40,OpenSync: Format Conversion,0.39,normal,,,