On Fri, 2015-07-10 at 15:12 +0100, Graham Cobb wrote:
I have just noticed that events are being corrupted when syncing
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
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.