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
|
