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/syncevolution-1-3/testing-amd64/14-exchange/
http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-3/testing-amd64/15-googleeas/

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 <[email protected]>
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.


_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to