Does it make sense if I sent you via private message a App Password so that you could reproduce both issues?
Yes, if it is account specific, please send the data using “chat” / private message or the contact form on https://www.davx5.com/contact
I am using DAVDroid 188.8.131.52-ose with OpenTasks 184.108.40.206, 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.
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.
Thanks. The verbose logs of the whole thing would be important …
PUT, which is allowed. However, DAVdroid has to do a further
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
PUT, DAVdroid depends on later downloading the resource.
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
ETagof the uploaded resource.
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
ETagto 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.