evolution plugin lost records occasionally

YuLei <yulei-cn+wHBRG/qiBUy7/[email protected]> Thu, 12 Aug 2004 17:59:42 +0800
Newsgroups gmane.comp.gnome.apps.multisync.devel
Message-ID <1092304782.31584.39.camel@localhost>
I have 411 records on my palm, database of evolution has just been
cleaned up, every time I use Resync to copy all the palm records to
evolution, some records will be lost, the number of missing records is
randomly, maybe 4 or 10 and even more.
tried the lastest branch_08X cvs version, the same problem.

After some days tracing, the following is the tracing results

--- ---------------------------------------------------------------
--- evo_addr_seqcompl_cb enter, addr_mode=EVO_ADDR_MODE_MODIFIED
--- evo_addr_modify_next enter, conn->modify_no=3
--- evo_addr_modify_next obj->change_type=SYNC_OBJ_ADDED
--- evo_addr_modify_next call e_book_add_vcard, conn->modify_no=4
--- evo_addr_modify_next call e_book_add_vcard finish
--- evo_addr_modify_next leave
--- evo_addr_seqcompl_cb leave
--- evo_addr_seqcompl_cb enter, addr_mode=EVO_ADDR_MODE_GOT_CHANGE
--- evo_addr_seqcompl_cb leave
--- evo_addr_seqcompl_cb enter, addr_mode=EVO_ADDR_MODE_GOT_CHANGE
--- evo_addr_seqcompl_cb leave
--- evo_addr_change enter, change_type=SYNC_OBJ_ADDED
addr_mode=EVO_ADDR_MODE_MODIFIED
--- evo_addr_change leave
--- evo_addr_change enter, change_type=SYNC_OBJ_ADDED
addr_mode=EVO_ADDR_MODE_WAITING
--- evo_addr_change leave
--- evo_addr_change enter, change_type=SYNC_OBJ_ADDED
addr_mode=EVO_ADDR_MODE_WAITING
--- evo_addr_change leave
--- evo_addr_add_cb enter, conn->modify_no=4
--- evo_addr_add_cb leave

>>> above tracing records are right, but the following records seems
strange,
>>> the callback function evo_addr_seqcompl_cb of next record was called
before evo_addr_add_cb
--- ---------------------------------------------------------------
--- evo_addr_seqcompl_cb enter, addr_mode=EVO_ADDR_MODE_MODIFIED
--- evo_addr_modify_next enter, conn->modify_no=4
--- evo_addr_modify_next obj->change_type=SYNC_OBJ_ADDED
--- evo_addr_modify_next call e_book_add_vcard, conn->modify_no=5
--- evo_addr_modify_next call e_book_add_vcard finish
--- evo_addr_modify_next leave
--- evo_addr_seqcompl_cb leave
--- evo_addr_seqcompl_cb enter, addr_mode=EVO_ADDR_MODE_GOT_CHANGE
--- evo_addr_seqcompl_cb leave
--- evo_addr_seqcompl_cb enter, addr_mode=EVO_ADDR_MODE_GOT_CHANGE
--- evo_addr_seqcompl_cb leave
--- evo_addr_change enter, change_type=SYNC_OBJ_ADDED
addr_mode=EVO_ADDR_MODE_MODIFIED
--- evo_addr_change leave
--- evo_addr_change enter, change_type=SYNC_OBJ_ADDED
addr_mode=EVO_ADDR_MODE_WAITING
--- evo_addr_change leave
--- evo_addr_change enter, change_type=SYNC_OBJ_ADDED
addr_mode=EVO_ADDR_MODE_WAITING
--- evo_addr_change leave
--- ---------------------------------------------------------------
--- evo_addr_seqcompl_cb enter, addr_mode=EVO_ADDR_MODE_MODIFIED
--- evo_addr_modify_next enter, conn->modify_no=5
--- evo_addr_modify_next obj->change_type=SYNC_OBJ_ADDED
--- evo_addr_modify_next call e_book_add_vcard, conn->modify_no=6
--- evo_addr_modify_next call e_book_add_vcard finish
--- evo_addr_modify_next leave
--- evo_addr_seqcompl_cb leave
--- evo_addr_seqcompl_cb enter, addr_mode=EVO_ADDR_MODE_GOT_CHANGE
--- evo_addr_seqcompl_cb leave
--- evo_addr_seqcompl_cb enter, addr_mode=EVO_ADDR_MODE_GOT_CHANGE
--- evo_addr_seqcompl_cb leave
--- evo_addr_add_cb enter, conn->modify_no=6
--- evo_addr_add_cb leave
--- evo_addr_change enter, change_type=SYNC_OBJ_ADDED
addr_mode=EVO_ADDR_MODE_MODIFIED
--- evo_addr_change leave
--- evo_addr_change enter, change_type=SYNC_OBJ_ADDED
addr_mode=EVO_ADDR_MODE_WAITING
--- evo_addr_change leave
--- evo_addr_change enter, change_type=SYNC_OBJ_ADDED
addr_mode=EVO_ADDR_MODE_WAITING
--- evo_addr_change leave
--- evo_addr_add_cb enter, conn->modify_no=6
--- evo_addr_add_cb result->returnuid != NULL 
--- evo_addr_add_cb leave

seems that the function e_book_add_vcard will accumulate the call to
evo_addr_add_cb.
any ideas ?