From: Armin B. <arm...@de...> - 2005-09-22 08:35:34
|
Right. Here is the problem: Ignoring a conflict works by saving the ignored uids of changes in a database. During the next sync, the devices wont send the changes again, so i have to read them explicitly using a special function. But if the plugin does not provide such function, the assertion will be triggered. Now we have 3 possible solutions to this: - either make sure that every plugins provides a read function (not really possible) - if one of the plugins does not provide a read function, do not provide a ignore resolution. - if one of the plugins does not provide a read function, slow-sync the next synchronization. so... what do you think would be the best solution? Armin Martin Felis wrote: > Hello, > > it looks like opensync has some problems when handling mapping > conflicts. > > I have a syncing group with evo2-sync and file-sync. I only have some > items in evo. > > The first sync went fine and when I provoked a conflict and tried to > ignore it, all went fine, too. > > But the third sync I got this error: > ** ERROR **: file opensync_member.c: line 1065 > (osync_member_read_change): assertion failed: (fmtsink->functions.read ! > = NULL) > aborting... > > The fourth sync found mapping conflict in every item (ignoring worked), > but again the next sync failed, like in the third sync. > > I tried to find out where the problem might be, but couldn't find real > solutions. I only found out, that if you > delete .opensync/groupX/changelog.db, the third sync works fine. > > I've added the traces, for the first, second, third, and the fourth > sync. > > martn |