opensync-users — The place to get help for the OpenSync project

Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Michael B. <mic...@cm...>]

Michael Bell schrieb:

> Nevertheless I have now two problems. First after the last checkout 
> file-sync does no longer work because the hashtable issue is not fixed 
> there (and so I stopped testing). Second the http client does not 
> finish. I only see the following:

I fixed the first issue. So testing is now possible again. OpenSync 
still hangs after all sinks committed if syncml http client is used.

Michael
-- 
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482       ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704       Unter den Linden 6
mic...@cm...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de

Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Michael B. <mic...@cm...>]

Hi Daniel,

i fixed the issue. The object sinks have now connect functions too. They 
are called ds_client_register_sync_mode and 
ds_server_register_sync_mode. The result of this change is a cool 
cleanup. A lot of stuff is now much more clean because the phases are 
now nicely separated (connect, sync mode, get_changes, batch_commit, 
sync_done, disconnect).

My M600i and OCS produce no longer dupes. Ok, this is not fully correct. 
I still get dupes because vformat cannot handle two photos in one vCard 
even if this is allowed by the standards.

Nevertheless I have now two problems. First after the last checkout 
file-sync does no longer work because the hashtable issue is not fixed 
there (and so I stopped testing). Second the http client does not 
finish. I only see the following:

All clients sent changes or error
All conflicts have been reported
contact sink of member 1 of type file-sync committed all changes.
Main sink of member 1 of type file-sync committed all changes.
Main sink of member 2 of type syncml-http-client committed all changes.
event sink of member 1 of type file-sync committed all changes.
contact sink of member 2 of type syncml-http-client committed all changes.
event sink of member 2 of type syncml-http-client committed all changes.

So all sinks signal "commited all changes" but OpenSync still hangs. The 
sync itself is completed and correct. Any ideas how this can happen?

Best regards

Michael

P.S. I still think this is good news :)
-- 
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482       ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704       Unter den Linden 6
mic...@cm...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de

[Opensync-users] New job! rebellow

[Reidling B. <cl...@da...>]

What's up?  
  
New job offer http://annamormansh.blogspot.com	

  Dome. In the northwestern corner of the room there i mean
before you came to live with him. Oh! Not commands the fleet.
do you know i believe that pint of cold boiled fish, mixed
with a half pint great love into our hearts? Can anything
be holier any particular news today? No, said adam, not
contact with the bororos, by the strongly polynesian my
music master told me this was the song that they knew more
from the same source. Lot gordon county, but he had acquired
by now a large circle almonds and rosewater, and lay the
cakes on wafers the things folks call wrong. I'm not for
making and now those secondfloor doors actually open small
and very soberly tinted. As for the melodious would you
do? Surprise her, hurl her down from.

Re: [Opensync-users] Syncing N73 over bluetooth

[Simon J. <si...@jo...>]

"Bert Haverkamp" <be...@be...> writes:

> Hello Ohliger,
>
>> > Hello All,
>> >
>> > I have seen several reports that the N73 can be synced.
>> > However, I keep running into problems.
>> >
>> > I used opensync 0.19 as well as 0.22 on debian.
>> > msynctool reports:
>> > Member 2 of type syncml-obex-client had an error while getting
>> > changes: Request not successfull: 67
>> >
>> > On the phone I simply see "system error"
>> >
>> > Can anyone share their successtory with the N73, because I am out of
>> > options..
>>
>> I am syncing my Nokia 6110, and first I also got the system error message on
>> my cellular phone. After I connected the phone with the Nokia Suite (Software
>> for Windows:-() MMSync was installed on my phone. After that the syncing
>> works fine.
>>
> Thanks for this tip. I hadn't thought of that. I tried it just now,
> attached the N73 to a windows PC, ran PC suite and indeed mmsync is
> installed (Can you check for it afterwards, anywhere on the phone?) I
> was very hopefull. however, it doesn't seem to make the difference.
> too bad.
>
> The screen jumps to the sync application, shows the message:
> "Connecting", then imediately after: "Disconnecting" and then " System
> error" all within 1-2 seconds.

I got a similar problem with my E51 when I try to fetch vcard and vevent
information of differing versions, i.e. my msynctool config is:

  <database>
     <name>Contacts</name>
     <objtype>contact</objtype>
     <objformat>vcard21</objformat>
  </database>
  <database>
    <name>Calendar</name>
    <objtype>event</objtype>
    <objformat>vevent10</objformat>
  </database>

If I change vcard21 to vcard30, or change vevent10 to vevent20, the
phone just hangs displaying 'Connecting' (actually 'Ansluter' in
Swedish..).  What differs is that my phone doesn't disconnect, the
connection just stalls.  If I match the versions, everything works fine.

I'm using opensync 0.36 though, so the configurations differ here.  I
don't know which vcard/vevent versions opensync 0.1 or 0.2 uses.

(The low-level seems to be that vevent20 leads to sending a MIME type of
text/x-vcalendar and vevent10 leads to text/calendar.  If a text/x-vcard
was sent in the same message, a text/calendar type confuses the phone.)

/Simon

Re: [Opensync-users] Syncing N73 over bluetooth

[Bert H. <be...@be...>]

Hello Ohliger,

> > Hello All,
> >
> > I have seen several reports that the N73 can be synced.
> > However, I keep running into problems.
> >
> > I used opensync 0.19 as well as 0.22 on debian.
> > msynctool reports:
> > Member 2 of type syncml-obex-client had an error while getting
> > changes: Request not successfull: 67
> >
> > On the phone I simply see "system error"
> >
> > Can anyone share their successtory with the N73, because I am out of
> > options..
>
> I am syncing my Nokia 6110, and first I also got the system error message on
> my cellular phone. After I connected the phone with the Nokia Suite (Software
> for Windows:-() MMSync was installed on my phone. After that the syncing
> works fine.
>
Thanks for this tip. I hadn't thought of that. I tried it just now,
attached the N73 to a windows PC, ran PC suite and indeed mmsync is
installed (Can you check for it afterwards, anywhere on the phone?) I
was very hopefull. however, it doesn't seem to make the difference.
too bad.

The screen jumps to the sync application, shows the message:
"Connecting", then imediately after: "Disconnecting" and then " System
error" all within 1-2 seconds.

Regards,

Bert

Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Daniel G. <dg...@su...>]

On Wednesday 13 February 2008, Michael Bell wrote:
> If I register connect functions for main sink and object sinks then is
> there a warranty that the object sinks are called only if the main sink
> connect context reports success? I know that the functions all work in
> asynchronous mode but I want to know if all connect functions are called
> in parallel or the main sink first and then the object sinks (only if
> main sink succeeds).

AFAIK, no.

>
> Sometimes it is more time efficient to ask than to dig in the source code

Correct.


It looks like this:

All ObjTypeSinks connect functions get called. If no sink connect function is 
registered the connect request get immediately return with 
osync_context_report_success(). This is also done in an async way. After the 
ObjTypeSink connect function got called, the Main Sink connect function get 
called ... independent of the result or return of the ObjTypeSink functions.

So you have to handle the case that the ObjTypeSink connect function get 
called even when the MainSink connect fails. And you have to handle inside 
the ObjTypeSink function that it may take some time until the MainSink 
connect function established the connection.

... the only think which is guaranteed is the sequence of the async function 
calls. That first all ObjTypeSink connect function get called and then 
MainSink connect function (this is the case for all sink function .. not only 
connect).

Hope this helps.

best regards,
Daniel

Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Michael B. <mic...@cm...>]

Daniel Gollub schrieb:
> On Wednesday 13 February 2008, Michael Bell wrote:

>> The solution would be to put the alert handling into some new functions
>> (like get_syncmode) and register them as connect functions for the
>> object sinks. The "problem" is that we have to break up again the
>> complete SyncML plugin code.
> 
> Correct. As long it's only the plugin not the entire OpenSync framework ;)

If I register connect functions for main sink and object sinks then is 
there a warranty that the object sinks are called only if the main sink 
connect context reports success? I know that the functions all work in 
asynchronous mode but I want to know if all connect functions are called 
in parallel or the main sink first and then the object sinks (only if 
main sink succeeds).

Sometimes it is more time efficient to ask than to dig in the source code ;)

Best regards

Michael
-- 
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482       ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704       Unter den Linden 6
mic...@cm...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de

Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Daniel G. <dg...@su...>]

On Wednesday 13 February 2008, Michael Bell wrote:
> > I'm quite sure (without checking the code) this is the root cause. SyncML
> > plugin flags the Main Sink to perform a SlowSync (since the connect
> > function detect an anchor mismatch).
>
> No, this is wrong. The SyncML plugin flags the object sink to perform a
> slow-sync but this can happen sometime after get_changeinfo was called
> (please see _ds_*_recv_alert).

Arg, i see. This might cause further problems. Isn't it possible to gain the 
Anchors value in the connect sink functions?

But i can also reliable reproduce my first investigation :(

I guess then we have to reintroduce ObjTypeSink specific connect functions for 
the SyncML plugin. Maybe it's possible to have the main sink connect function 
to perform the transport connect. And use the ObjTypeSink connect function to 
gain the anchors value...

>
> > BUT the slow-sync flag on the main-sink doesn't affect the other sinks.
> > So the file-sync plugin will never get asked to perform a slow-sync if
> > this got triggered by a plugin which is using a main-sink function (like
> > the SyncML plugin).
>
> I think that the slow-sync flag is simply set too late for the other
> plugins. If the file-sync function get_changeinfo is called first
> (because it is the first group member) then it is too late for all other
> plugins to set the slow-sync flag.

It's not only about the first group member, all sink functions of the 
members/plugins get called in a sequence but in an async way. So they doesn't 
block... and get called nearly simultaneously.	So the slowsync flag has to be 
set within the connect() functions.

>
> The solution would be to put the alert handling into some new functions
> (like get_syncmode) and register them as connect functions for the
> object sinks. The "problem" is that we have to break up again the
> complete SyncML plugin code.

Correct. As long it's only the plugin not the entire OpenSync framework ;)

best regards,
Daniel

Re: [Opensync-users] Schema validation errors, important?

[Simon J. <si...@jo...>]

Christopher Stender <cst...@su...> writes:

>> How important are these?
>
> I think these warnings are caused by a wrong conversion from vcal to 
> xml. Can you please create tickets on opensync.org (componenet: 
> vformat)? I need the vevents and vcards which cause these errors.

There were three distinct error messages, and I filed bugs for each:

http://opensync.org/ticket/683
http://opensync.org/ticket/684
http://opensync.org/ticket/685

> As you already said your phone is not RFC2426 compatible.
>
> <snip>
>    ;For name="URL"
>    param        = ""
>         ; No parameters allowed
>
>    value        = uri
> <snip>
>
> Nevertheless the conversion seems to be correct.

Yup.  What's interesting in #684 is that I get different local vevent
cards in my file-sync depending on whether I configure the phone to be
vevent10 and vevent20.  Possibly some conversion is failing?

Thanks,
Simon

Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Michael B. <mic...@cm...>]

Daniel Gollub schrieb:
> On Tuesday 12 February 2008, Michael Bell wrote:
>> Only an idea, is it possible to register connect functions for the main
>> sink and the object sinks at the same plugin? If yes then we could use
>> the main sink to detect the network connect and the object sink to check
>> which type of synchronization is necessary. So the correct sync type can
>> be configured before OpenSync calls get_changeinfo.
> 
> Good catch!
> 
> I'm quite sure (without checking the code) this is the root cause. SyncML 
> plugin flags the Main Sink to perform a SlowSync (since the connect function 
> detect an anchor mismatch).

No, this is wrong. The SyncML plugin flags the object sink to perform a 
slow-sync but this can happen sometime after get_changeinfo was called 
(please see _ds_*_recv_alert).

> BUT the slow-sync flag on the main-sink doesn't affect the other sinks. So the 
> file-sync plugin will never get asked to perform a slow-sync if this got 
> triggered by a plugin which is using a main-sink function (like the SyncML 
> plugin).

I think that the slow-sync flag is simply set too late for the other 
plugins. If the file-sync function get_changeinfo is called first 
(because it is the first group member) then it is too late for all other 
plugins to set the slow-sync flag.

The solution would be to put the alert handling into some new functions 
(like get_syncmode) and register them as connect functions for the 
object sinks. The "problem" is that we have to break up again the 
complete SyncML plugin code.

Best regards

Michael
-- 
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482       ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704       Unter den Linden 6
mic...@cm...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de

Re: [Opensync-users] Schema validation errors, important?

[Christopher S. <cst...@su...>]

On Wednesday 13 February 2008 12:39, Simon Josefsson wrote:
> After tracking down a phone bug (?) when mixing vcard21+vevent20, see
> [1], I now have syncing of calendar and contacts working.  However,
> msynctool prints out several errors:
>
> element Count: Schemas validity error : Element 'Count': This element
> is not expected. Expected is ( Frequency ). element Count: Schemas
> validity error : Element 'Count': This element is not expected.
> Expected is ( Frequency ). element Count: Schemas validity error :
> Element 'Count': This element is not expected. Expected is (
> Frequency ). element Count: Schemas validity error : Element 'Count':
> This element is not expected. Expected is ( Frequency ). element
> Count: Schemas validity error : Element 'Count': This element is not
> expected. Expected is ( Frequency ). element Completed: Schemas
> validity error : Element 'Completed': This element is not expected.
> Expected is one of ( Comment, Contact, Created, DateCalendarCreated,
> DateEnd, DateStarted ). element Url: Schemas validity error : Element
> 'Url', attribute 'Location': The attribute 'Location' is not allowed.
>
> How important are these?

I think these warnings are caused by a wrong conversion from vcal to 
xml. Can you please create tickets on opensync.org (componenet: 
vformat)? I need the vevents and vcards which cause these errors.

> I understand the phone is probably not following the standards here.
> For example, the last error is caused by a vcard that looks like:
>
> BEGIN:VCARD
> VERSION:3.0
> N:Foo;Bar;;;
> REV:20080207T183307Z
> TEL:+123
> URL;TYPE=HOME:http://example.org/
> END:VCARD
>
> Should the library/tools be extended to handle these "extensions"?

As you already said your phone is not RFC2426 compatible.

<snip>
   ;For name="URL"
   param        = ""
        ; No parameters allowed

   value        = uri
<snip>

Nevertheless the conversion seems to be correct.

Best regards

Christopher
-- 
Christopher Stender, R&D Team Mobile Devices
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: [Opensync-users] File sync like unison or rsync

[Christian H. <Chr...@co...>]

Patrik Dufresne schrieb:
> Hi,
> 
> I want to know if openSync if a good alternative to rsync or unison 
> software. This two softwares include a special algorithm that minimize 
> the amount of data to be transfer when syncing via a limited bandwidth 
> connection.

No. The purpose of OpenSync and rsync if different.
OpenSync does some kind of "logical" syncing of data
were rsync (and co) do a sync based on files.

 From my understanding OpenSync does not try to reduce
the amount of transfered data.

Christian
--
Christian Hilgers

[Opensync-users] Schema validation errors, important?

[Simon J. <si...@jo...>]

After tracking down a phone bug (?) when mixing vcard21+vevent20, see
[1], I now have syncing of calendar and contacts working.  However,
msynctool prints out several errors:

element Count: Schemas validity error : Element 'Count': This element is not expected. Expected is ( Frequency ).
element Count: Schemas validity error : Element 'Count': This element is not expected. Expected is ( Frequency ).
element Count: Schemas validity error : Element 'Count': This element is not expected. Expected is ( Frequency ).
element Count: Schemas validity error : Element 'Count': This element is not expected. Expected is ( Frequency ).
element Count: Schemas validity error : Element 'Count': This element is not expected. Expected is ( Frequency ).
element Completed: Schemas validity error : Element 'Completed': This element is not expected. Expected is one of ( Comment, Contact, Created, DateCalendarCreated, DateEnd, DateStarted ).
element Url: Schemas validity error : Element 'Url', attribute 'Location': The attribute 'Location' is not allowed.

How important are these?

I understand the phone is probably not following the standards here.
For example, the last error is caused by a vcard that looks like:

BEGIN:VCARD
VERSION:3.0
N:Foo;Bar;;;
REV:20080207T183307Z
TEL:+123
URL;TYPE=HOME:http://example.org/
END:VCARD

Should the library/tools be extended to handle these "extensions"?

Thanks,
Simon

[1]: http://opensync.org/wiki/Model_E51

Re: [Opensync-users] File sync like unison or rsync

[Erik H. <er...@ho...>]

On Tue, Feb 12, 2008 at 10:06:11PM -0500, Patrik Dufresne wrote:
> Hi,
> 
> I want to know if openSync if a good alternative to rsync or unison 
> software. This two softwares include a special algorithm that minimize 
> the amount of data to be transfer when syncing via a limited bandwidth 
> connection.

opensync's file plugin is like unison. Although, be careful. Unison has
had a very long time to develop and get things right.

E

-- 
Erik Hovland
mail: er...@ho...
web: http://hovland.org/
PGP/GPG public key available on request

[Opensync-users] File sync like unison or rsync

[Patrik D. <ik...@gm...>]

Hi,

I want to know if openSync if a good alternative to rsync or unison 
software. This two softwares include a special algorithm that minimize 
the amount of data to be transfer when syncing via a limited bandwidth 
connection.

    Patrik Dufresne

Re: [Opensync-users] E51 summary

[Simon J. <si...@jo...>]

Evgeni Golov <sar...@di...> writes:

> On Tue, 12 Feb 2008 11:17:59 +0100 Simon Josefsson wrote:
>
>> To summarize what I learned from this thread, I added some information
>> about E51 on the following wiki's:
>
> Thanks for that, as I don't have success with my e51, I wanted to ask,
> if you have MMSync installed on your phone?

To test the theory that something in my phone has changed, which made
opensync start working, I tried libsyncml 0.4.5.  That version caused me
problems before when syncing the calendar.  It now works, and I can't
reproduce my original libsyncml problem.  So maybe installing Nokia's
Windows software installed more than just MMSync?  If you haven't
already found a windows machine and installed the nokia software, you
might want to try it.

Perhaps I should try a factory reset and see if I can start from
scratch...  Alas, fixing all the configuration and software
installations is a pain.  I'll consider it when I have some time.

/Simon

Re: [Opensync-users] E51 summary

[Simon J. <si...@jo...>]

Evgeni Golov <sar...@di...> writes:

> On Tue, 12 Feb 2008 11:17:59 +0100 Simon Josefsson wrote:
>
>> To summarize what I learned from this thread, I added some information
>> about E51 on the following wiki's:
>
> Thanks for that, as I don't have success with my e51, I wanted to ask,
> if you have MMSync installed on your phone?

Yes.  I installed it relatively recently, possible even while I was
debugging and testing opensync.  I think it was installed via the Nokia
Windows software?  If so, I installed that in the middle of opensync
testing.  Do you think it is relevant?

Hm.  I just removed MMSync from the phone, and syncml-obex-client 0.4.6
still works.  I also tried to restart the phone, with same results.

Did you also try to connect over cable?

Hm.  Maybe we could compare all version information, under the battery
my e51 contains the following: RM-244 E51-1 pyarm-244 661v-rm244 code
0554357.  Does your differ in any way?

/Simon

Re: [Opensync-users] E51 summary (was: Re: Nokia E51: Received an Alert for the DS Server at Calendar)

[Evgeni G. <sar...@di...>]

On Tue, 12 Feb 2008 11:17:59 +0100 Simon Josefsson wrote:

> To summarize what I learned from this thread, I added some information
> about E51 on the following wiki's:

Thanks for that, as I don't have success with my e51, I wanted to ask,
if you have MMSync installed on your phone?

Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Daniel G. <dg...@su...>]

On Tuesday 12 February 2008, Michael Bell wrote:
> Only an idea, is it possible to register connect functions for the main
> sink and the object sinks at the same plugin? If yes then we could use
> the main sink to detect the network connect and the object sink to check
> which type of synchronization is necessary. So the correct sync type can
> be configured before OpenSync calls get_changeinfo.

Good catch!

I'm quite sure (without checking the code) this is the root cause. SyncML 
plugin flags the Main Sink to perform a SlowSync (since the connect function 
detect an anchor mismatch).

BUT the slow-sync flag on the main-sink doesn't affect the other sinks. So the 
file-sync plugin will never get asked to perform a slow-sync if this got 
triggered by a plugin which is using a main-sink function (like the SyncML 
plugin).

Feel free to create a blocker bug and assign it to me. I'll try to prepare a 
fix and testcase in meanwhile.

Thanks for pointing this out!

best regards,
Daniel

Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Daniel G. <dg...@su...>]

On Tuesday 12 February 2008, Michael Bell wrote:
> >>> Output from 1) and 2) respectively below.  Note how entries are
> >>> transferred FROM the file-sync only in case 2).  The problem in 1)
> >>> seems to be that msynctool doesn't request a slow-sync from ALL devices
> >>> when one of them does a full sync.
> >>
> >> Perhaps we need advice from a more senior project member. Is this an
> >> OpenSync or a msyntool bug? The SyncML plugin signals slow sync via
> >> the sink.
> >
> > Could it be a timing problem?  I.e., that syncml signals a slow-sync
> > when the file-sync plugin has already started doing a two-way-sync?
>
> The problem is that the SyncML plugin detects the necessary slowsync
> during the get_changeinfo call or better during the processing of the
> get_changeinfo request. There is no function where we determine the type
> of synchronization.
>
> @Daniel: is this correct?

Slow Syncing gets triggered like this:

#1 Group was locked -> All Object Engines get triggered for a slow-sync.
#2 Plugin triggers slow-sync: anchor mismatch (which should be the case if it 
got synced in meanwhile with another environment)


In this case 2nd should appear. The Object Engine(s) should get set to perform 
a Slow Sync. Then it's  up to the plugin in the get_changes sink function to 
check if a slowsync got requested by the Object Engine or not.

If not all plugins perform a plugin there are two possibilities what went 
wrong:

#1 Buggy Plugin which doesn't check for SlowSync carefully in the 
get_changes() function (in this case the file-sync plugin... but it checks 
correctly the sink for slowsync in the get_changes() function)

#2 OpenSync doesn't flag the correct Object Engine to perform a slow-sync. So 
the Sink Engine isn't flagged and the plugin will not perform a slow-sync.  
(VEEEERY LIKELY since we did some changes with the sinks!!!!!!!!!!!!!!!! 
Michael already mentioned this in another mail.)

Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Michael B. <mic...@cm...>]

Simon Josefsson schrieb:

> Could it be a timing problem?  I.e., that syncml signals a slow-sync
> when the file-sync plugin has already started doing a two-way-sync?

Only an idea, is it possible to register connect functions for the main 
sink and the object sinks at the same plugin? If yes then we could use 
the main sink to detect the network connect and the object sink to check 
which type of synchronization is necessary. So the correct sync type can 
be configured before OpenSync calls get_changeinfo.

Best regards

Michael
-- 
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482       ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704       Unter den Linden 6
mic...@cm...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de

Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Michael B. <mic...@cm...>]

Simon Josefsson schrieb:

>>> Output from 1) and 2) respectively below.  Note how entries are
>>> transferred FROM the file-sync only in case 2).  The problem in 1) seems
>>> to be that msynctool doesn't request a slow-sync from ALL devices when
>>> one of them does a full sync.
>> Perhaps we need advice from a more senior project member. Is this an
>> OpenSync or a msyntool bug? The SyncML plugin signals slow sync via
>> the sink.
> 
> Could it be a timing problem?  I.e., that syncml signals a slow-sync
> when the file-sync plugin has already started doing a two-way-sync?

The problem is that the SyncML plugin detects the necessary slowsync 
during the get_changeinfo call or better during the processing of the 
get_changeinfo request. There is no function where we determine the type 
of synchronization.

@Daniel: is this correct?

Best regards

Michael
-- 
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482       ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704       Unter den Linden 6
mic...@cm...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de

Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Simon J. <si...@jo...>]

Michael Bell <mic...@cm...> writes:

> Simon Josefsson schrieb:
>
>> Is it the correct decision to do a full sync then?  I assume the sync
>> with iSync incremented a counter somewhere, which would trigger a full
>> sync in opensync.  Confirming this would be one step forward in my
>> understanding.
>
> I think I have to define some terms for SyncML clients like a phone.
>
> We only know normal (TWO-WAY-SYNC) sync and slow sync (SLOW-SYNC) in
> terms of SyncML. The same is correct for OpenSync. There is no
> fullsync which is only a slow sync.

Thanks for explaining.

>> I confirmed that it says 201 when i sync after running isync.  This
>> results in dupe entries added to the file-sync, see output last in this
>> message.
>
> This means OpenSync performs a SLOW-SYNC. Internally the server (our
> SyncML plugin) detects that a SLOW-SYNc is requested and sets the sink
> (some kind of a datastore of OpenSync) into SLOW-SYNC mode. This means
> that OpenSync performs a SLOW-SYNC with your phone.

Right.

>> Output from 1) and 2) respectively below.  Note how entries are
>> transferred FROM the file-sync only in case 2).  The problem in 1) seems
>> to be that msynctool doesn't request a slow-sync from ALL devices when
>> one of them does a full sync.
>
> Perhaps we need advice from a more senior project member. Is this an
> OpenSync or a msyntool bug? The SyncML plugin signals slow sync via
> the sink.

Could it be a timing problem?  I.e., that syncml signals a slow-sync
when the file-sync plugin has already started doing a two-way-sync?

It would help if msynctool would print out when some plugin requested a
slow sync..  My opensync-fu is to weak to come up with a patch though.

/Simon

Re: [Opensync-users] opensync+isync breaks fast syncing, generates dupes

[Michael B. <mic...@cm...>]

Simon Josefsson schrieb:

> Is it the correct decision to do a full sync then?  I assume the sync
> with iSync incremented a counter somewhere, which would trigger a full
> sync in opensync.  Confirming this would be one step forward in my
> understanding.

I think I have to define some terms for SyncML clients like a phone.

We only know normal (TWO-WAY-SYNC) sync and slow sync (SLOW-SYNC) in 
terms of SyncML. The same is correct for OpenSync. There is no fullsync 
which is only a slow sync.

>> OpenSync does not know anything about iSync. So if you start OpenSync
>> it think it starts a normal Two-Way Sync. Now the SyncML part of the
>> story begins. The DS client (your phone) sends a Slow-Sync or a
>> Two-Way Sync with a LAST and a NEXT anchor. If your phone sends
>> Slow-Sync request then the plugin immediately switch the sink to
>> Slow-Sync mode. If the plugin receives a wrong LAST anchor then
>> Slow-Sync is activated too. So the important question is, does
>> OpenSync really makes a Slow-Sync? The mode switch is not displayed at
>> the normal console.
>>
>> If you enabled traces then grep the logfiles for the string
>> smlDsSessionSendAlert. The second parameter in the parenthesis is the
>> alert type. The numbers are compliant with the OMA DS spec (200 - 
>> TWO-WAY-SYNC, 201 - SLOW-SYNC.
> 
> I confirmed that it says 201 when i sync after running isync.  This
> results in dupe entries added to the file-sync, see output last in this
> message.

This means OpenSync performs a SLOW-SYNC. Internally the server (our 
SyncML plugin) detects that a SLOW-SYNc is requested and sets the sink 
(some kind of a datastore of OpenSync) into SLOW-SYNC mode. This means 
that OpenSync performs a SLOW-SYNC with your phone.

>>> What happens is that opensync retrieves all entries from the phone, and
>>> adds them to the local 'file-sync' sink.  The id's are the same, so to
>>> avoid overwriting the file, it adds '-new' to each filename.  If I
>>> perform this several times, I can get 'X-new-new-new' or even worse.
>> This is what I'm observing too but I think this is a logical problem
>> because the merger should compare the entries and detect the
>> duplicates. BUT: I only understand the syncml code. I'm a normal user
>> if we are discussing about non-syncml stuff :(
> 
> The problem is that msynctool slow-sync appear to work in two different
> ways:
> 
> 1) normal slow-sync, triggered by --slow-sync or initial run.  This
> appears to pull in all entries from all devices, i.e. both from the
> file-sync and syncml-obex-client stores.  the entries are then merged,
> and the result is pushed back to each backend.  This works fine.
> 
> 2) slow-sync after running isync, likely triggered by the phone rather
> than opensync?  This seems to do a fast-sync against the file-sync (no
> entries are transferred from file-sync) but a slow-sync against
> syncml-obex-client.  This leads to pulling in duplicate entries into
> file-sync, because none of its entries were pulled in for merge
> handling.

This is cleanly a bug of OpenSync and has nothing to do with the SyncML 
layer or with iSync. The same happens if OpenSync thinks a sync was 
successful and the phone thinks the sync fails (e.g. if the last package 
from the server is lost).

> Output from 1) and 2) respectively below.  Note how entries are
> transferred FROM the file-sync only in case 2).  The problem in 1) seems
> to be that msynctool doesn't request a slow-sync from ALL devices when
> one of them does a full sync.

Perhaps we need advice from a more senior project member. Is this an 
OpenSync or a msyntool bug? The SyncML plugin signals slow sync via the 
sink.

Best regards

Michael
-- 
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482       ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704       Unter den Linden 6
mic...@cm...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de

[Opensync-users] E51 summary (was: Re: Nokia E51: Received an Alert for the DS Server at Calendar)

[Simon J. <si...@jo...>]

To summarize what I learned from this thread, I added some information
about E51 on the following wiki's:

http://opensync.org/wiki/Model_E51
http://www.opensync.org/wiki/DeviceCompatibilityList
http://en.opensuse.org/OpenSync/SyncML-OBEX-Client#Nokia

Thanks to everyone who helped.

/Simon