[SyncEvolution] super data store: trying to read to check for existance

Hello! A SyncEvolution user found that SyncEvolution fails while synchronizing against a mobile phone when an item was deleted on both the phone and Evolution side. SyncEvolution is asked to read the already deleted item, which then fails (currently) with an unspecified database error. This is due to the following code: #20 0x00000000009b89de in sysync::TSuperDataStore::engProcessRemoteItem (this=0x1166900, syncitemP=0xe854e0, aStatusCommand=...) at /home/pohly/syncevolution/libsynthesis/src/sysync/superdatastore.cpp:637 637 regular=linkP->fDatastoreLinkP->logicRetrieveItemByID(*itemcopyP,aStatusCommand); (gdb) list 632 PDEBUGPRINTFX(DBG_DATA+DBG_DETAILS,( 633 "Trying to read item by remoteID='%s' from subdatastore '%s' to see if it is there", 634 itemcopyP->getRemoteID(), 635 linkP->fDatastoreLinkP->getName() 636 )); 637 regular=linkP->fDatastoreLinkP->logicRetrieveItemByID(*itemcopyP,aStatusCommand); 638 // must be ok AND not 404 (item not found) 639 if (regular && aStatusCommand.getStatusCode()!=404) { 640 PDEBUGPRINTFX(DBG_DATA,( 641 "Item found in subdatastore '%s', deleting it there", Why is it necessary to read before trying to delete? If the item exists, then reading it is a fairly expensive test. So far, my backends were written with the expectation that they have to cope with delete requests for items which are already deleted. This follows from the inherent race condition between syncing and some other process which might delete items while a sync runs. Are all backends expected to return 404 when an item doesn't exist? -- 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.