Re: [Opensync-users] Assertion when ignoring mapping conflict (fwd)

[Martin F. <ma...@si...>]

Sorry, I didn't reply to the list, so the conversation went "offline". Here's
the last message from Armin:

----- Weitergeleitete Nachricht von Armin Bauer <arm...@de...> -----
    Datum: Thu, 22 Sep 2005 12:10:15 +0200
    Von: Armin Bauer <arm...@de...>
Antwort an: Armin Bauer <arm...@de...>
 Betreff: Re: [Opensync-users] Assertion when ignoring mapping conflict
      An: Martin Felis <ma...@si...>

Martin Felis wrote:
> Hello,
> 
> I think the second is the best because slow-sync might take very long
> time, so I would like to avoid them. Another thing is, that the developers
> would implement such a function, since it would add a quite important
> feature and you would get as close as possible to the first solution.
> I thought however of a modified second solution: If one of the plugins
> does not provide a read function and does not use hashes, do not provide
> an ignore resolution.

Hmm... right. we just have to overwrite the hash in the database with
NULL so that just the key remains. The next sync it will definetly get
reported as modified. Good idea :)

But we have to make changes to the gui/cli as well so that they dont
show the "ignore" option if it could not be used.

Armin

> Because when using hashes, the ignoration would simply mean "take the
> new hash, but do not send the change to the other members", so a simple
> change.db update can do it.
> 
> Martin
> 
> Zitat von Armin Bauer <arm...@de...>:
> 
>>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
>>
> 
> 
> 

----- Ende der weitergeleiteten Nachricht -----