[SyncEvolution] partially successful syncs (MB #7755)

Hello! I'm looking at issue 7755, "[ERROR] calendar: calendar: extracting event / sync successful?!". I turned out that when local operations fail, this was counted by the Synthesis engine, but not per ADD/UPDATE/REMOVE. Therefore the "rejected" column in the following output was always zero: +---------------|-------ON CLIENT-------|-------ON SERVER-------|-CON-+ | | rejected / total | rejected / total | FLI | | Source | NEW | MOD | DEL | NEW | MOD | DEL | CTS | +---------------+-------+-------+-------+-------+-------+-------+-----+ | vcard30 | 1/17 | 0/0 | 0/16 | 0/0 | 0/0 | 0/0 | 0 | | refresh-from-server, 0 KB sent by client, 14 KB received | | item(s) in database backup: 16 before sync, 16 after it | +---------------+-------+-------+-------+-------+-------+-------+-----+ | start Thu Jan 14 19:35:54 2010, duration 0:04min | | synchronization completed successfully | +---------------+-------+-------+-------+-------+-------+-------+-----+ In this particular example I already enhanced libsynthesis so that the failed ADD is recorded separately. For remote items I'm less sure whether counting per operation is possible. Those cases that I have found in the code which increment the global fRemoteItemsError counter don't seem to have good access to the failed operation. I'm not even sure whether the counter is accurate. Now, my question is this: should we keep printing "synchronization completed successfully" in such a case? It means the overall status for the session was okay, because it completed. That doesn't sounds right to me. I suggest that when we detect problematic items, we record for the affected source and for the whole session a new "STATUS_PARTIAL_SUCCESS = 22001" status, similar to "STATUS_UNEXPECTED_SLOW_SYNC = 22000". The return code from syncevolution should indicate a failure. If we have automatic sync enabled, it should stop to let the user deal with the problem before it gets worse. How does that sound? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.