On Mon, 2013-03-04 at 22:46 +0000, Graham Cobb wrote:
> I have found a problem with activesyncd with Exchange. In my case, the
> Exchange server has lost state (no idea why, but I noticed that my Android
> phone has thrown away all my mail and resynchronised it all so I guess it saw
> it too).
>
> The effect is that when I tried a sync, the server said "Mailbox folders are
> not synchronized, need FolderSync first". And when I force a folder sync,
> the
> server rejects the folder SyncKey ("SyncFolder error: Invalid synchronization
> key").
>
> My guess is that if I delete the folder cache file the key will go back to 0
> and everything will work. But I am trying to find a way to handle the
> problem
> in the code. I am considering four options in increasing order of complexity:
>
> 1) The easiest option seems to be to change the get_folder code to never do
> real folder syncs. Whenever the client asks for a folder list with retrieval
> from the server, just throw away the cache so the server will send all the
> folders (instead of updates, as happens today). This seems a bit extreme but
> it seems the easiest option, and folder lists seem unlikely to be much longer
> than a few contacts or events. It means that user intervention is necessary
> to fix the actual problem but the user can be told that when they see the
> "need FolderSync first" error they need to use "--print-databases" to force
> the FolderSync.
>
> 2) A cheat: detect either a "need FolderSync first" error (in any
> transaction)
> or an "Invalid synchronization key" error in a folder sync and discard the
> folder cache at that time (but don't attempt to refetch it from the server
> automatically). The user will still need to do a "--print-databases" to
> reload the folder cache when they notice the error being reported, but we
> save
> always reloading the folder list when we don't need to.
>
> 3) Add code to detect and handle the "Invalid synchronization key" error in a
> folder sync: throw away the cache when that happens, and then repeat the
> folder sync. I am not sure the extra complexity is worth it for what should
> be
> an unusual problem, I hope (and the user still has to notice the problem and
> request the folder sync).
>
> 4) Handle the problem completely automatically: combine one of the other
> options with code that spots a "need FolderSync first" error in any
> transaction and does the folder sync automatically (much as provisioning
> happens transparently).
>
> Any thoughts? My current idea is to implement option 1 and watch to see if
> this is a problem which happens often. If so, I guess options 4+3 is the
> right answer.
Even if it is an uncommon problem, expecting users to perform some
manual operation to resolve it is not going to work well.
I'm speaking from experience here ;-) SyncEvolution intentionally
prevents slow syncs and asks the users how he wants to proceed. Both the
command line and the GTK UI have fairly detailed error messages with
usage instructions included, and still users regularly show up who did
not understand how to deal with the problem.
In that case, SyncEvolution couldn't automatically pick a solution which
is guaranteed to not result in data loss or data mangling, because it
simply didn't know anymore in which state client and server were.
For folder sync the situation is different. There is an automatic
response which does not involve data loss, so that's what should happen
without involving the user. Of course, implementing it is a different
matter...
--
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
