On Fri, 2015-07-10 at 15:12 +0100, Graham Cobb wrote: > I have just noticed that events are being corrupted when syncing from > Exchange. > > The problem is that when an event changes, EAS can send a "change" > notification, with only the fields that have changed, not the whole new > event. activesyncd then creates a partial (and invalid!) VEVENT with > only the changed fields.
I agree, that cannot work in the current architecture. But I am less sure why it occurs or how it was meant to be handled. > The question is, what do I do about this? Is there any way for > syncevolution to process updates and merge them with the existing > object? Nothing that would be easy to use. The Synthesis engine has support for merging fields into an existing item, but that is configured based on capabilities of the peer and not per item. If we were to configure the ActiveSync side of the sync such that the engine is told that it supports no property at all, then the engine would always preserve local properties unless explicitly overwritten. However, that then breaks removing properties which *were* removed on the ActiveSync side. What we would need is a "this is an incremental update" flag per item. Even with such a flag, any discrepancy in granularity between the ActiveSync protocol, iCalendar and the internal field list would still be a source of potential problems. Example: ActiveSync elements foo and bar map to iCalendar FOOBAR, which then maps to foo and bar again in the field list (or even something different again). If the server changes foo and does not send bar, what would the activesyncd server put into FOOBAR? > If not, does activesyncd have to go and refetch the entire > updated object from Exchange? I think that would be the more realistic solution. I also wonder whether the server can be told to avoid incremental updates in the first place. -- 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] https://lists.syncevolution.org/mailman/listinfo/syncevolution
