On 26/10/16 15:21, Patrick Ohly wrote: > I am using the policy-key workaround, but haven't actually verified > whether it is needed.
I haven't done exhaustive testing, but I think it is needed if the policy-key in gsettings would otherwise be reset (i.e. null). In other words, if you are completely deleting the gsettings and recreating them you need something non-null in the policy-key. If you are not recreating them then they will already have a non-null (and possibly even correct) value. Yes, that raises the question of why the code doesn't check the value of policy-key when it is loaded and change a null value to something else (say 0)! >With the work-around, I am running into a problem > (see > https://nightly.syncevolution.org/2016-10-26-05-27_exchange_sanity_release-eas-jessie-amd64_prebuilt-jessie-amd64_trusty-amd64/prebuilt-jessie-amd64/21-exchange/ > and > https://nightly.syncevolution.org/2016-10-26-05-27_exchange_sanity_release-eas-jessie-amd64_prebuilt-jessie-amd64_trusty-amd64/prebuilt-jessie-amd64/21-exchange/Client_Source_eas_contact_testImport.log.html): > basically any attempt to create some item on the Exchange server fails with > an error code 12 = > GDBus.Error:org.meego.activesyncd.SyncError.FolderHierarchyChanged: Sync > error: Mailbox folders are not synchronized, need FolderSync first > > Here's a snippet from the activesyncd.log: > > ... > (process:111:0xf61d090): libeas-DEBUG:> POST > /Microsoft-Server-ActiveSync?Cmd=Sync&User=nigh...@ouvku.hostedoffice.ag&DeviceId=aaaaaaa99cb14effac6a8f447AAAAAAA&DeviceType=MeeGo > HTTP/1.1 > (process:111:0xf61d090): libeas-DEBUG:> Soup-Debug-Timestamp: 1477486033 > (process:111:0xf61d090): libeas-DEBUG:> Soup-Debug: SoupSessionAsync 1 > (0xf623b90), SoupMessage 10 (0x147a7170), SoupSocket 11 (0x147d23a0) > ... > (process:111:0xf61d090): libeas-DEBUG:Received 12 bytes for request 0x14793f00 > (process:111:0xf61d090): libeas-DEBUG:< HTTP/1.1 200 OK > (process:111:0xf61d090): libeas-DEBUG:< Soup-Debug-Timestamp: 1477486034 > (process:111:0xf61d090): libeas-DEBUG:< Soup-Debug: SoupMessage 10 > (0x147a7170) > (process:111:0xf61d090): libeas-DEBUG:< Cache-Control: private > (process:111:0xf61d090): libeas-DEBUG:< Content-Type: > application/vnd.ms-sync.wbxml > ... > (process:111:0xf61d090): libeas-DEBUG:eas_connection - wbxml2xml++ > (process:111:0xf61d090): libeas-DEBUG: > === dump start: xml_len [168] === > <?xml version="1.0"?> > <!DOCTYPE ActiveSync PUBLIC "-//MICROSOFT//DTD ActiveSync//EN" > "http://www.microsoft.com/";> > <Sync xmlns="AirSync:"> > <Status>12</Status> > </Sync> > === dump end === > > That is with your "workround folder sync when server loses state" patch > applied. > > Any idea how to proceed with this? Is the policy-key workaround perhaps > not working as intended? No, it is nothing to do with policy-key. That gives different symptoms: either OK status but 0-length response or some 4nn status (419? I can't remember). It looks like the problem is that a FolderSync is needed. You need to use --print-databases. See the "Problems" in the Wiki page. All my patch in bug 61869 does is enable --print-databases to be used as a manual workround for this problem. It doesn't attempt to solve it automatically. If I remember correctly, one reason I didn't try to fix it automatically is that I couldn't reproduce the problem! If you can reproduce the problem reliably then maybe we can try to really fix it. By the way, this raises a couple of interesting questions for your build testing. The EAS support (in the backend and in activesyncd) keeps state (in ~/.cache/activesync, in gsettings, and in the wallet). You might want to think about whether your automated testing wants to make sure it destroys all that state before running. _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
