GNOME Bugzilla – Bug 665065
Updates changed items forever
Last modified: 2011-12-07 09:31:18 UTC
I'm using PidLastModificationTime to identify changes of the item in evo-mapi. It's not the best approach, but it is usually sufficient. If I enable the evo-ews account and let it refresh the Inbox, then each message in the Inbox has changed this property and makes evo-mapi believe the item changed, even it didn't in reality. This is cased by SyncFolderItems call from EWS. I guess it should rather use FindItem, as it's a similar way how evo-mapi is fetching items from folders.
I suppose these are related: http://msdn.microsoft.com/en-us/library/ee218364%28v=EXCHG.80%29.aspx http://msdn.microsoft.com/en-us/library/ee178773%28v=EXCHG.80%29.aspx
This sounds like a bug in Exchange — it shouldn't be changing the modification time on individual messages, when they haven't changed. If you use the PidTagChangeNumber or PidTagChangeKey properties that you mention in comment #1, instead of PidLastModificationTime, does that still have the problem?
Also, does this happen only the *first* time the Inbox is opened with EWS (and the message is mentioned in a SyncFolderItems response), or on all subsequent SyncFolderItems calls which don't touch the old messages in any way?
Current git master, before 3.3.3, evo-mapi at least commit 6e724da (I found I do not save summary, though it had only minor impact on this). Steps: a) Configure two accounts, one ews and one mapi, both for the same server b) select one folder in mapi account, let it fetch its summary c) select other non-ews folder, then back to the same mapi folder - observer the refresh of the folder was significantly quicker (nothing changed) d) select the same folder in ews, let it finish the update e) select back the same mapi folder, see the refresh fetches whole summary change is 1322751703->1322753435 in last notify. My messages do not have PidTagChangeNumber, but they have PidTagChangeKey: 19 A9 51 63 10 61 BE 42 8E D3 21 53 71 65 3D 6A ..Qc.a.B ..!Sqe=j 01 F8 BF 9A 9A DB ...... f) select other folder, then back to mapi, refresh is quick g) select the same ews folder from d) and let it to the sync h) select folder from e), it changed again, 1322753435->1322753558 and the key 19 A9 51 63 10 61 BE 42 8E D3 21 53 71 65 3D 6A ..Qc.a.B ..!Sqe=j 01 F8 BF 9A 9A FB ...... See the increment in the last digit. I can repeat d), e) for ever. Note the evolution instance wasn't closed at all, it all is during one run. I do not think this is an issue on the server. Its version: > Mailbox server Microsoft Exchange version: 8.1.240.0
Created attachment 202511 [details] ema debug patch
Hm, and even an EWS SyncFolderItems call which returns *no* changes is enough to trigger this change in the ChangeKey of all messages? That *definitely* smells like a server bug.
(In reply to comment #6) > Hm, and even an EWS SyncFolderItems call which returns *no* changes is enough > to trigger this change in the ChangeKey of all messages? Yes, I only selected a folder in evolution where changed basically nothing and all the messages are touched on the server. > That *definitely* smells like a server bug. I do not think so. the protocol specification is not clear on this (better said I didn't find anything what would support your or mine hypothesis for sure), but I think it works the same for your server as well. It will be good if you can try. Maybe the closes description lies here: http://msdn.microsoft.com/en-us/library/ee160594%28v=EXCHG.80%29.aspx
The document you link to says, "A new change number is assigned to a messaging object each time it is modified.". It doesn't explicitly say that it *isn't* assigned a new change number when it *isn't* modified, but common sense would seem to suggest that. I appreciate that applying common sense to Microsoft Exchange is not often a fruitful exercise ;) That quote is also about "change number" not "change key", but again, common sense would seem to suggest that the change key would not change unless the message is actually modified, either. If you perform the almost-identical Sync call with ActiveSync (either from evolution-eas or another client), does this also have the same effect on the messages?
I'm sorry, I'm not running activesync, and I'm not going to in the near future.
Created attachment 202908 [details] [review] proposed ews patch for evolution-ews; After explanation from David about syncing I finally found the cause for this. It's because ews doesn't work with CAMEL_MESSAGE_FOLDER_FLAGGED flag properly. Once the changes are saved to the server the ews should unset the flag, to indicate the message info is up-to-date. Because it didn't do that then it requested update of each flagged item in the folder whenever the synchronize_sync was invoked. With this patch the change to last modification, neither to changekey, is done.
Review of attachment 202908 [details] [review]: Looks good; thanks.
Created commit cfe9229 in ews master (3.3.3+)