Updated task contens lost after sync

---

Hi,

I am using DAVDroid 1.5.0.2-ose with OpenTasks 1.1.8.2, both from F-Droid, with mailbox.org.

So I first create one shopping list and add a couple of items to it. I save the task and it gets synchronized to mailbox.org.
After this I open the task again and add a couple of more items to the list. I save the task. Shortly after this a new sync is triggered.
After the sync the newly added items are lost from the list and only the contents which was added on task creating is present.
This happens every time.
So it seems that in this case the data on the server is considered to be newer, or whatever, and the “server wins”.

This is not the wanted behaviour, is it? I would expect, that in this case the client wins.

Regerds
hkemal

Can you please provide debug info and verbose logs so that we can see what’s happening? Sounds like the server takes some time to process the changes, and then the server-processed version is synced to the client.

When using DAVdroid, the server always wins – DAVdroid won’t overwrite changed data on the server. This approach should work for your use-case.

Hi,

1. created task Shoplist, added 2 checklist items and set a due date.
2. after a couple of minutes I open the task again and added 2 more checklist items.
3. after a couple of minutes I checked the task, changes made in step 2 are gone.

Thanks. The verbose logs of the whole thing would be important …

@rfc2822
link text

1. mailbox.org doesn’t return an ETag on PUT, which is allowed. However, DAVdroid has to do a further PROPFIND/REPORT, get the ETag and download the resource again to make sure it’s the same version as referenced in the ETag. So, in short: when a server doesn’t return an ETag on PUT, DAVdroid depends on later downloading the resource.
2. mailbox.org says that the folder content (CTag) hasn’t changed even after the first task has been uploaded. So, there’s no need for DAVdroid to download the (changed) resources. So, DAVdroid doesn’t get the real ETag of the uploaded resource.
3. Because DAVdroid doesn’t know the ETag, it assumes that the task has just been created at the second upload. So it sets If-None-Match: * (“don’t overwrite anything”). This precondition and this the second upload attempt fails. Then, mailbox.org says the CTag has changed in the meanwhile, which causes the resource and its ETag to be downloaded and everything works.

In my opinion, this is a server problem. After uploading the first task, the CTag should change, which would cause DAVdroid to download the task again and know it’s ETag. Further uploads should then work.

I guess that this is caused by a slow server which takes some time until changes are accepted. However, the CTag should change nevertheless as soon as the first task is uploaded.

Please report this to mailbox.org.