On occasion, the ActiveSync server loses state and insists that the client refetches the folder list with folder sync key 0. Currently there is no way for the user to fix that, except finding the folder cache file and deleting it.
The attached patches add a hack to handle this case and allow folder syncs to recover. The hack is that folder syncs **always** restart from sync key 0. This means that when the problem occurs, the user can recover by forcing a folder sync (for example using --print-databases).
There are two patches. The first patch, 0001-eas-daemon-add-eas_connection_forget_folders.patch, is not a hack. This adds the capability to reset the folder sync, which is required in any solution to the problem.
The second patch, 0001-eas-daemon-workround-folder-sync-when-server-loses-s.patch, is the hack. This always calls eas_connection_forget_folders before doing a folder sync. This could be optimised further in future if desired.
Created attachment 75976 [details] [review]
This patch is not the hack -- it is needed for any solution to the problem
Created attachment 75977 [details] [review]
Hack to always fetch folder list from scratch
I have included these patches in a for-master/folder-sync-hack branch, which means that SyncEvolution will include them when building activesyncd binaries and source archives.
As discussed on the mailing list ("[SyncEvolution] Activesync server losing state"
http://thread.gmane.org/gmane.comp.mobile.syncevolution/4295), a better solution would be to detect the issue and do the sync with key 0 automatically if and only if needed.
I'll keep the issue open with no particular assignee.
Created attachment 76128 [details] [review]
ignore "file not found" when deleting key file
Setting up an account in a clean environment with these two patches applied failed in the regular testing with a "Error removing file: No such file or directory".
The fix was simple... ;-) It's part of the for-master branch and I'll use it in SyncEvolution 18.104.22.168.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/157.