@TheDoctorII yes, would have been a lot easier if they did…
@henry-nicolas Can you maybe test the new version 0.6.12 (see https://davdroid.bitfire.at/configuration for configuration details) and tell us if it works for you?
Inconsistency in DavDroid's sync algorithm?
-
Reposting from https://github.com/bitfireAT/davdroid/issues/578#issuecomment-124746482, since it’s sort of off-topic, yet I think it’s an important discussion to have:
I think I understand now what was irking me about DavDroid’s behavior:
delete every local non-dirty contacts that are not on the server anymore
The items with
@are being treated inconsistently by DavDroid. First it assumes they’re on the server and therefore adds them to the addressbook, later it thinks they are not on the server and deletes them locally.So I think the way DavDroid handles invalid multiget-responses such as the one from ownCloud is problematic. Encoding errors happen all the time, and while I don’t think DavDroid is in a place to work around those, it should abort sync if:
- the response contains unsolicited items
- is missing items that have been requested. Unfortunately Radicale doesn’t allow between a finer distinction of 404-status and a missing status. At least not until https://github.com/Kozea/Radicale/pull/259 is widely used.
-
Where is the “inconsistency” in DAVdroid?
As far as I understand, you only suggest to sanity-check server responses for inconistencies.
The items with @ are being treated inconsistently by DavDroid.
In #578, there are not items with “@” in the file name, as PROPFIND returns items with “%40” in the name.
-
As said, “First it assumes they’re on the server and therefore adds them to the addressbook, later it thinks they are not on the server and deletes them locally”.
First it thinks they (the resources with unencoded
@) are on the server:DAVdroid requests these two (new) members from OwnCloud and adds all resources from the response. The response however does not contain the requested members, but 20140623T00123.086fed@foo.bar.vcf.vcf and /owncloud/remote.php/carddav/addressbooks/test/kontakte/20140623T46782.acdf@foo.bar.vcf.vcf. These resources are added nevertheless (because DAVdroid expects them to be the requested ones, and it has to trust the server-given resource names to distinguish between the resources).
later it thinks they are not on the server and deletes them locally:
In the last step (“delete every local non-dirty contacts that are not on the server anymore”), DAVdroid deletes everything except 20140623T00123.086fed%40foo.bar.vcf.vcf (unencoded) and 20140623T46782.acdf%40foo.bar.vcf.vcf, so the recently fetched resources are deleted immediately (because their names are 20140623T00123.086fed@foo.bar.vcf.vcf and /owncloud/remote.php/carddav/addressbooks/test/kontakte/20140623T46782.acdf@foo.bar.vcf.vcf).
Emphasis mine.
As far as I understand, DavDroid constructs a href-set of resources that are on the server, which contains
20140623T00123.086fed%40foo.bar.vcf.vcfand20140623T46782.acdf%40foo.bar.vcf.vcfafter the initial PROPFIND. However, when the server responds tomultigetwith20140623T00123.086fed@foo.bar.vcf.vcfand/owncloud/remote.php/carddav/addressbooks/test/kontakte/20140623T46782.acdf@foo.bar.vcf.vcf, those hrefs should be added to that set too.Yes, what I’m basically proposing is a sanity-check.
-
As said, “First it assumes they’re on the server and therefore adds them to the addressbook, later it thinks they are not on the server and deletes them locally”.
The only problem I see is that the entries which are returned by REPORT are not the ones requested by DAVdroid (= the ones returned from PROPFIND = the ones “assumed” to be on the server).
So this additional (and optional) sanity check could verify that the records returnd by REPORT are the ones requested by DAVdroid.
This would be “nice to have” but at least I don’t see an inconsistency on DAVdroid’s side.
-
I’ve edited my post multiple times, I think this paragraph summarizes my concerns the best:
As far as I understand, DavDroid constructs a href-set of resources that are on the server, which contains 20140623T00123.086fed%40foo.bar.vcf.vcf and 20140623T46782.acdf%40foo.bar.vcf.vcf after the initial PROPFIND. However, when the server responds to multiget with 20140623T00123.086fed@foo.bar.vcf.vcf and /owncloud/remote.php/carddav/addressbooks/test/kontakte/20140623T46782.acdf@foo.bar.vcf.vcf, those hrefs should be added to that set too.
I think a sanity-check is important in the context of missing events or tasks that may become overdue without the user noticing. This doesn’t apply with ownCloud where only contacts are affected, but I imagine other servers have similar issues too.
-
I think a sanity-check is important in the context of missing events or tasks that may become overdue without the user noticing. This doesn’t apply with ownCloud where only contacts are affected, but I imagine other servers have similar issues too.
I beliebve I still don’t understand the problem. Do you see any problems in current DAVdroid behaviour if the server works correctly?
-
Do you see any problems in current DAVdroid behaviour if the server works correctly?
No, but I see problematic behavior (silently skipping items) if the server does not work correctly.
I don’t really care whether you store recieved items you didn’t ask for and delete them later, although it strikes me as a bit imperformant. I don’t know enough about the algorithm you’re using – perhaps it’s easier to implement in your case.
-
I’m just considering such a sanity check, but I wonder what DAVdroid should do when the server returns
- additional, unrequested items (should never happen, but who knows) and/or
- not all of the requested items, but without error message (in case that the resource has vanished between PROPFIND and REPORT, the server should report status 404 for that resource).
Is it really wise to interrupt the sync with a hard error and show a user notification in these cases?
-
Show warnings but continue sync. I wonder if it’s better to create a per-account activity to show all warnings for a server than to throw that stuff into the notification area.
On 28 July 2015 19:53:50 CEST, rfc2822 notifications@github.com wrote:
I’m just considering such a sanity check, but I wonder what DAVdroid
should do when the server returns- additional, unrequested items (should never happen, but who knows)
and/or - not all of the requested items, but without error message (in case
that the resource has vanished between PROPFIND and REPORT, the server
should report status 404 for that resource).
Is it really wise to interrupt the sync with a hard error and show a
user notification in these cases?
Reply to this email directly or view it on GitHub:
https://github.com/bitfireAT/davdroid/issues/587#issuecomment-125694082–
Sent from my phone. Please excuse my brevity. - additional, unrequested items (should never happen, but who knows)
-
I had the same problem and here is the workaround I used : https://github.com/bitfireAT/davdroid/issues/578#issuecomment-126699251