https://bugs.freedesktop.org/show_bug.cgi?id=77065
--- Comment #9 from Patrick Ohly <[email protected]> --- (In reply to comment #3) > It is unclear at the moment to me why the engine handled PHOTO like that. > The "merge" attribute was not set, so it shouldn't have concatenated. Need > to check. It didn't do that when I was checking. That means that there is an unidentified bug in the code somewhere. I consider this issue here unresolved until we find out what it is. Updating the merge script hides the problem and is the right solution for photo merging, but it merely hides the reason for the corruption, it doesn't solve it. Renato, as I can't reproduce the problem, can you investigate? Running valgrind would be my first step. Next comes running under gdb. The merge script compares photo data but doesn't write to it, so the two sides should still be okay when MERGEFIELDS(mode) gets called. You can set a breakpoint in sysync::TMFTypeFuncs::func_MergeFields for that. You need to find the code which prints: [2014-04-04 19:06:36.981] Field 'PHOTO' available and enabled for merging, mode/sep=0x00FE, relevant [2014-04-04 19:06:36.981] - assigned in winning / assigned in loosing [2014-04-04 19:06:36.981] - try merging winning value 'file:///home/phablet/.local/share/evolut' with loosing value '�PNG ' [2014-04-04 19:06:40.469] merged something, winning value is 'file:///home/phablet/.local/share/evolut' [2014-04-04 19:06:40.469] Winning and loosing Field 'PHOTO' not equal: 'file:///home/phablet/.local/sh' <> '�PNG ' [2014-04-04 19:06:40.469] - updated fields such that both have same value 'file:///home/phablet/.local/share/evolut' And then check the content of the fields for corruption. Later, the local item is corrupted: [2014-04-04 19:06:40.488] TStdLogicDS: Item updated with contents from remote [2014-04-04 19:06:40.488] Item LocalID='pas-id-533EBFB40000000E', RemoteID='76045616125e182d', operation=replace, size: [maxlocal,maxremote,actual] [2014-04-04 19:06:40.488] ... - 75 : string PHOTO [ 0, 0,636325] : "file:///home/phablet/.local/share/evolution/add...0� �ǐ��0���B��+�%�m9���V�ԭ� - 76 : string PHOTO_TYPE [ 0, 0, 7] : "unknown" - 77 : string PHOTO_VALUE [ 0, 0, 3] : "uri" The item that gets sent back to remote is also corrupted: [2014-04-04 19:06:41.423] 'Item_Generate' - generating SyncML item, SyncOp=replace, RemoteID=76045616125e182d [--][++] [->end] [->enclosing] + [2014-04-04 19:06:41.424] 'ScriptExecute' - Start executing Script, name=outgoingscript [--][++] [->end] [->enclosing] [2014-04-04 19:06:41.441] Generating.... [2014-04-04 19:06:41.441] Item LocalID='', RemoteID='76045616125e182d', operation=replace, size: [maxlocal,maxremote,actual] ... - 75 : string PHOTO [ 0, 0,636325] : "file:///home/phablet/.local/share/evolution/add...0� �ǐ��0���B��+�%�m9���V�ԭ� - 76 : string PHOTO_TYPE [ 0, 0, 0] : <unassigned> - 77 : string PHOTO_VALUE [ 0, 0, 3] : "uri" -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ Syncevolution-issues mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution-issues
