Re: [SyncEvolution] Memotoo refresh + empty data

On So, 2011-08-21 at 15:00 +0200, Thomas Pequet wrote: > Le 19/08/2011 17:36, Patrick Ohly a écrit : > > testDeleteAllRefresh: > > 1. four items in sync on client and server > > 2. client deletes all items, asks for refresh-from-client => no > > items transferred > > 3. slow sync to verify => four items recreated on client > > > > The server seems to have ignored the request to delete its data before > > syncing in step 2. Is that intentional? > OK now the four items will be deleted in server at 2. > I have modified Memotoo. Confirmed, worked in the latests tests: http://syncev.meego.com/latest/head-testing-amd64/nightly.html#memotoo However, something else broke. Now "testDelete" fails for all data categories. For example, contacts: http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_db... The problem is an unexpected slow sync, instead of the desired two-way sync. This is the same problem as for testOneWayFromServer, see below. > > testOneWayFromServer: > > 1. client A, B and server empty > > 2. client A add one item, sends to server > > 3. client B adds one item locally, does one-way-from-server > I can not arrive to reproduce this test ... > My SyncEvolution send Data "200" instead of "204" for "one-way-from-server" Sorry, I was looking at the wrong log (testOneWayFromClient instead of testOneWayFromServer). > > The client asks for a 202 sync in its Alert > > (http://syncev.meego.com/2011-08-19-07-20_testing_memotoo/head-testing-amd...). > OK now Memotoo will return the anchor. Still fails. The latest test results for testOneWayFromServer are here: http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_db... The one-way-from-server sync is this: http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_db... And here the message: http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_db... Note that the Synthesis engine asks for a normal, incremental sync. I suspect that it does the one-way sync like that by simply not telling the server about its own changes. The problem occurs when the sync has to fall back to a two-way slow sync, because then items from the client do get sent to the server, in contrast to the initial intention. IMHO this is a problem in the Synthesis engine logic. But there's not much that can be done in that case, except asking the users (as SyncEvolutions "prevent slow sync" logic would do, if it was active). The main problem is the fallback to a slow sync. Why does the server ask for one? http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_db... The client sent 20110823T194959Z as its last anchor and sc-pim-B as its LocURI, which matches the values from the previous sync: http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_db... http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_db... Between these two syncs there was another one from the client sc-api-A: http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_db... http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_db... That also is an unexpected slow sync, but it doesn't show up as a failure because the end result happens to be as desired. Normally SyncEvolution's testing would check the sync mode and detect this, but for Memotoo that is disabled because we had these cases where it did unexpected slow syncs legitimately (no data on server). Is it possible that the server doesn't properly distinguish between multiple clients?