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.
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
