6:33 a.m.
On Fr, 2013-01-11 at 17:52 +0000, Graham Cobb wrote:
I solved my first problem: MIcosoft was returning a 403 error to the
Sync
command because there was no X-MS-PolicyKey. When I changed to code to always
add "X-MS-PolicyKey: 0" if there was no policy_key already set, the server was
happy (it triggered provisioning, of course, so a non-zero policy key was used
for later commands). I thought that a missing X-MS-PolicyKey should be the
sme as X-MS-PolicyKey: 0 but that does not seem to be the case, at least with
this server.
That then leads me on to the next problem... The initial Sync command
activesyncd sends is being rejected with an error:
Mailbox folders are not synchronized, need FolderSync first
Am I supposed to configure folder information in syncevolution manually? Or
should activesyncd be doing a FolderSync?
activesyncd should do the FolderSync automatically and then pick the
default folder for address book and calendar if no specific folder was
configured.
I remember that this automatism is fragile; I had random,
non-deterministic failures where the folder ID was empty in messages
sent to the server. I made some changes to in when preparing
SyncEvolution 1.3, but I could not really identify the exact root cause.
Below is the relevant commit; perhaps you can find something in the code
that I touched there that fails with your server.
It might also help to compare against the activesyncd debug output from
the SyncEvolution 1.3 nightly test. I archived them here:
http://downloads.syncevolution.org/syncevolution/archive/test-results/syn...
http://downloads.syncevolution.org/syncevolution/archive/test-results/syn...
The *.server.log files contain the activesyncd output for each test.
Tests are not entirely stateless though, because activesyncd is only
started once. Therefore it might be hard to find the initial sync where
the FolderSync is done for the first time.
commit 1a6086e841e9919311ddf7ac3802d8658e5b377d
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Fri Aug 31 19:30:14 2012 +0000
daemon: incomplete fix for invalid folder ID problem
While testing with Google contacts, tests randomly fail
with "Fetch or Change operation that has an id no longer valid on the
server".
The reason is an empty <CollectionID/>.
This patch adds debug messages around folder and collection ID
retrieval and fixes one potential problem (a goto jumped over
the code with sets priv->folderID), but that was not enough
to fix the problem.
The priv->folderID = eas_sync_folder_msg_get_def_con_folder()
code gets a NULL from the priv->syncFolderMsg, although previous
debug code shows that the right folders where found. Need to investigate
further.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.