On 07. aug. 2012 18:10, Patrick Ohly wrote: > 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.
As far as I can tell from the sources, at least KCalExtended's Tracker storage stores and selects on the stamp of the time stored in the received entry, not the local time of reception. It makes sense that the created-time and modified-time in the entry should be the time the *user* modified the data, otherwise sane conflict resolution becomes impossible. Thus, I'd say an implementation that does what you say is broken. (I did see one instance of possible brokenness in KCalExtended's SQLite backend regarding the created-time, but not in the Tracker backend, which is probably what's actually used here.) If the local storage time is of interest, it should probably be kept separate. And KCalExtended doesn't bother with keeping track of that, I think. > 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. Why would that be? If it cares, all the app needs to know is that the last-modification-time changed, it shouldn't need to be later than when the app last checked it. I don't think a non-syncing app should be able to assume too much about these things. Of course, this might make it inconvenient for the app to get a list of local changes, but most apps should have no need for that. When it's launched, it should simply load the entries it needs (probably based on start time), no matter when they were last modified, and then recheck its caches as needed (if the calendar storage isn't sophisticated enough to notify it or something). _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
