On Tue, 2012-08-07 at 17:41 +0200, Ove Kåven wrote: > On 07. aug. 2012 10:15, Patrick Ohly wrote: > >> Would > >> it be safer to generate the anchor in beginSync, so if the user does > >> anything during the sync, the next sync can catch it? > > > > Then changes made by SyncEvolution after beginSync() would be reported > > in the next sync as changes which need to be transmitted to the peer, > > which would be wrong. > > Is that really a big issue? I figured we're selecting on last > modification times here. By causality, assuming all clocks are mostly in > sync, typical events transmitted in a synchronization would have a > last-modification-time *before* the sync began, and that same > last-modification time would be replicated on the other side, and thus > also be before the beginSync time, and therefore, not picked up by the > next beginSync.
I'm thinking of the items which are added or modified during the sync on behalf of the remote peer. The last-modified stamp is that of the local storage, not the original one from the peer, and thus it is higher than the beginSync time stamp. It has to be assigned by the local storage, because if it is not, then a third party app on the local side will incorrectly conclude that a modified item is old and unmodified when in fact it was modified after that app last looked at the database. Some additional filtering could try to remove the "extra" changes, but it seems fairly elaborate to me and I have never tried it before. There's no support infrastructure in SyncEvolution for it. -- 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
