Menu
▾
▴
opensync-users
|
From: Simon J. <si...@jo...> - 2008-02-07 18:48:06
|
I have now isolated the problem that causes duplicates to be created. This is with libsyncml 0.4.6 and opensync (core library, file-sync, syncml, and msynctool) from svn. First I sync the phone with isync on Mac OS X. Then I create a opensync installation, one syncml-obex-client and one file sink. I sync once first, which is a slow sync, populating the local file sink. I sync again, and this time it is a fast sync, with no changes. I can also force a slow sync, which also works fine with no changes. The problem starts if I now sync the phone on the Mac. The sync on the mac works fine. When I after that try to synchronize using opensync, things break. What happens is that opensync decides to do a fast sync. Is that the correct decision? The output from this fast sync is below. 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. At this point, I have each entry twice in my local file sync. If I later sync again with the phone, it would probably transfer all entries from the file sink back to the phone (I prevent this by making the syncml-obex-client a read-only sink). This rapidly creates a lot of duplicates. Any ideas? I'll see if I can get a stable setup by always forcing slow-sync. /Simon jas@mocca:~$ msynctool --sync e51-file Synchronizing group "e51-file" contact sink of member 2 of type syncml-obex-client just connected contact sink of member 1 of type file-sync just connected Main sink of member 1 of type file-sync just connected Main sink of member 2 of type syncml-obex-client just connected All clients connected or error Main sink of member 2 of type syncml-obex-client just sent all changes contact sink of member 1 of type file-sync just sent all changes Main sink of member 1 of type file-sync just sent all changes Received an entry 15 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 24 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 27 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 52 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 58 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 61 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 63 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 80 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 101 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 120 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 121 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 127 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 137 from member 2 (syncml-obex-client). Changetype ADDED ... Received an entry 812 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 813 from member 2 (syncml-obex-client). Changetype ADDED element Url: Schemas validity error : Element 'Url', attribute 'Location': The attribute 'Location' is not allowed. Received an entry 814 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 815 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 816 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 817 from member 2 (syncml-obex-client). Changetype ADDED contact sink of member 2 of type syncml-obex-client just sent all changes All clients sent changes or error All conflicts have been reported Received an reply to our sync contact sink of member 2 of type syncml-obex-client committed all changes. Main sink of member 2 of type syncml-obex-client committed all changes. Sent an entry 15-new to member 1 (file-sync). Changetype ADDED Sent an entry 24-new to member 1 (file-sync). Changetype ADDED Sent an entry 27-new to member 1 (file-sync). Changetype ADDED Sent an entry 52-new to member 1 (file-sync). Changetype ADDED ... Sent an entry 812-new to member 1 (file-sync). Changetype ADDED Sent an entry 813-new to member 1 (file-sync). Changetype ADDED Sent an entry 814-new to member 1 (file-sync). Changetype ADDED Sent an entry 815-new to member 1 (file-sync). Changetype ADDED Sent an entry 816-new to member 1 (file-sync). Changetype ADDED Sent an entry 817-new to member 1 (file-sync). Changetype ADDED contact sink of member 1 of type file-sync committed all changes. Main sink of member 1 of type file-sync committed all changes. All clients have written contact sink of member 2 of type syncml-obex-client reported sync done. Main sink of member 2 of type syncml-obex-client reported sync done. contact sink of member 1 of type file-sync reported sync done. Main sink of member 1 of type file-sync reported sync done. All clients reported sync done The sync was successful contact sink of member 1 of type file-sync just disconnected Main sink of member 1 of type file-sync just disconnected contact sink of member 2 of type syncml-obex-client just disconnected jas@mocca:~$ |
|
From: Simon J. <si...@jo...> - 2008-02-07 19:35:48
|
Simon Josefsson <si...@jo...> writes: > I'll see if I can get a stable setup by always forcing slow-sync. FYI, there is semi-success here. There are no duplicates, but slow-syncing doesn't notice if I delete anything on the phone. The entry isn't removed in the local file sink. I hope this provides some useful information for someone. /Simon |
|
From: Michael B. <mic...@cm...> - 2008-02-08 10:09:38
Attachments:
smime.p7s
|
Simon Josefsson schrieb: > First I sync the phone with isync on Mac OS X. Then I create a opensync > installation, one syncml-obex-client and one file sink. I sync once > first, which is a slow sync, populating the local file sink. I sync > again, and this time it is a fast sync, with no changes. I can also > force a slow sync, which also works fine with no changes. > > The problem starts if I now sync the phone on the Mac. The sync on the > mac works fine. > > When I after that try to synchronize using opensync, things break. What > happens is that opensync decides to do a fast sync. Is that the correct > decision? Are you sure that a normal Two-Way Sync is performed? 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. > 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 :( 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 |
|
From: Simon J. <si...@jo...> - 2008-02-12 09:45:34
|
Michael Bell <mic...@cm...> writes: > Simon Josefsson schrieb: > >> First I sync the phone with isync on Mac OS X. Then I create a opensync >> installation, one syncml-obex-client and one file sink. I sync once >> first, which is a slow sync, populating the local file sink. I sync >> again, and this time it is a fast sync, with no changes. I can also >> force a slow sync, which also works fine with no changes. >> >> The problem starts if I now sync the phone on the Mac. The sync on the >> mac works fine. >> >> When I after that try to synchronize using opensync, things break. What >> happens is that opensync decides to do a fast sync. Is that the correct >> decision? > > Are you sure that a normal Two-Way Sync is performed? Oops, I typed wrong, I meant full sync there. I inferred this because the phone sent all contacts (1/123, 2/123, 3/123, ...), whereas for quick sync's, it just says 'Syncing..' or something like that. 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. > 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. >> 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. 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. Does this make sense to anyone who understand the opensync design better? Thanks, /Simon Output from running msynctool after isync: jas@mocca:~$ msynctool --sync e51-file Synchronizing group "e51-file" contact sink of member 2 of type syncml-obex-client just connected contact sink of member 1 of type file-sync just connected Main sink of member 1 of type file-sync just connected Main sink of member 2 of type syncml-obex-client just connected All clients connected or error Main sink of member 2 of type syncml-obex-client just sent all changes contact sink of member 1 of type file-sync just sent all changes Main sink of member 1 of type file-sync just sent all changes Received an entry 15 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 24 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 27 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 52 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 58 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 63 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 80 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 101 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 120 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 137 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 138 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 155 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 185 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 192 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 193 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 194 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 214 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 606 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 608 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 612 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 614 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 615 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 616 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 618 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 620 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 629 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 635 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 636 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 637 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 638 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 652 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 654 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 662 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 664 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 666 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 670 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 672 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 674 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 678 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 687 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 690 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 696 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 698 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 702 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 704 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 705 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 707 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 710 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 726 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 727 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 736 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 737 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 756 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 760 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 761 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 762 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 763 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 764 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 766 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 767 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 769 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 770 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 771 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 773 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 774 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 777 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 779 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 781 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 782 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 787 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 790 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 791 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 794 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 798 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 799 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 801 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 803 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 804 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 806 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 807 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 808 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 809 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 810 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 811 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 812 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 813 from member 2 (syncml-obex-client). Changetype ADDED element Url: Schemas validity error : Element 'Url', attribute 'Location': The attribute 'Location' is not allowed. Received an entry 814 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 815 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 816 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 817 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 819 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 820 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 821 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 822 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 826 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 827 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 828 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 829 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 830 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 831 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 838 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 839 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 840 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 841 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 842 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 843 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 844 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 845 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 846 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 847 from member 2 (syncml-obex-client). Changetype ADDED contact sink of member 2 of type syncml-obex-client just sent all changes All clients sent changes or error All conflicts have been reported Received an reply to our sync contact sink of member 2 of type syncml-obex-client committed all changes. Sent an entry 15-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 24-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 27-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 52-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 58-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 63-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 80-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 101-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 120-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 137-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 138-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 155-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 185-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 192-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 193-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 194-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 214-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 606-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 608-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 612-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 614-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 615-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 616-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 618-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 620-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 629-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 635-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 636-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 637-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 638-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 652-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 654-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 662-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 664-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 666-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 670-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 672-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 674-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 678-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 687-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 690-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 696-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 698-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 702-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 704-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 705-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 707-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 710-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 726-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 727-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 736-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 737-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 756-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 760-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 761-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 762-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 763-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 764-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 766-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 767-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 769-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 770-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 771-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 773-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 774-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 777-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 779-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 781-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 782-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 787-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 790-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 791-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 794-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 798-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 799-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 801-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 803-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 804-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 806-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 807-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 808-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 809-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 810-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 811-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 812-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 813-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 814-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 815-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 816-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 817-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 819-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 820-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 821-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 822-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 826-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 827-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 828-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 829-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 830-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 831-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 838-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 839-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 840-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 841-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 842-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 843-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 844-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 845-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 846-new-new to member 1 (file-sync). Changetype ADDED Sent an entry 847-new to member 1 (file-sync). Changetype ADDED 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-obex-client committed all changes. All clients have written contact sink of member 2 of type syncml-obex-client reported sync done. Main sink of member 2 of type syncml-obex-client reported sync done. contact sink of member 1 of type file-sync reported sync done. Main sink of member 1 of type file-sync reported sync done. All clients reported sync done The sync was successful contact sink of member 1 of type file-sync just disconnected Main sink of member 1 of type file-sync just disconnected contact sink of member 2 of type syncml-obex-client just disconnected ^C jas@mocca:~$ Output from running msynctool --slow-sync: jas@mocca:~$ msynctool --sync e51-file --slow-sync contact Synchronizing group "e51-file" [slow sync] The previous synchronization was unclean. Slow-syncing contact sink of member 2 of type syncml-obex-client just connected contact sink of member 1 of type file-sync just connected Main sink of member 1 of type file-sync just connected Main sink of member 2 of type syncml-obex-client just connected All clients connected or error Main sink of member 2 of type syncml-obex-client just sent all changes Received an entry 840 from member 1 (file-sync). Changetype ADDED Received an entry 804 from member 1 (file-sync). Changetype ADDED Received an entry 787 from member 1 (file-sync). Changetype ADDED Received an entry 790 from member 1 (file-sync). Changetype ADDED Received an entry 15 from member 1 (file-sync). Changetype ADDED Received an entry 702 from member 1 (file-sync). Changetype ADDED Received an entry 737 from member 1 (file-sync). Changetype ADDED Received an entry 678 from member 1 (file-sync). Changetype ADDED Received an entry 698 from member 1 (file-sync). Changetype ADDED Received an entry 727 from member 1 (file-sync). Changetype ADDED Received an entry 155 from member 1 (file-sync). Changetype ADDED Received an entry 838 from member 1 (file-sync). Changetype ADDED Received an entry 696 from member 1 (file-sync). Changetype ADDED Received an entry 839 from member 1 (file-sync). Changetype ADDED Received an entry 781 from member 1 (file-sync). Changetype ADDED Received an entry 214 from member 1 (file-sync). Changetype ADDED Received an entry 831 from member 1 (file-sync). Changetype ADDED Received an entry 618 from member 1 (file-sync). Changetype ADDED Received an entry 636 from member 1 (file-sync). Changetype ADDED Received an entry 705 from member 1 (file-sync). Changetype ADDED Received an entry 687 from member 1 (file-sync). Changetype ADDED Received an entry 817 from member 1 (file-sync). Changetype ADDED Received an entry 27 from member 1 (file-sync). Changetype ADDED Received an entry 841 from member 1 (file-sync). Changetype ADDED Received an entry 766 from member 1 (file-sync). Changetype ADDED Received an entry 774 from member 1 (file-sync). Changetype ADDED Received an entry 819 from member 1 (file-sync). Changetype ADDED Received an entry 637 from member 1 (file-sync). Changetype ADDED Received an entry 664 from member 1 (file-sync). Changetype ADDED Received an entry 80 from member 1 (file-sync). Changetype ADDED Received an entry 808 from member 1 (file-sync). Changetype ADDED Received an entry 764 from member 1 (file-sync). Changetype ADDED Received an entry 704 from member 1 (file-sync). Changetype ADDED Received an entry 63 from member 1 (file-sync). Changetype ADDED Received an entry 58 from member 1 (file-sync). Changetype ADDED Received an entry 185 from member 1 (file-sync). Changetype ADDED Received an entry 756 from member 1 (file-sync). Changetype ADDED Received an entry 816 from member 1 (file-sync). Changetype ADDED Received an entry 616 from member 1 (file-sync). Changetype ADDED Received an entry 615 from member 1 (file-sync). Changetype ADDED Received an entry 670 from member 1 (file-sync). Changetype ADDED Received an entry 810 from member 1 (file-sync). Changetype ADDED Received an entry 635 from member 1 (file-sync). Changetype ADDED Received an entry 809 from member 1 (file-sync). Changetype ADDED Received an entry 138 from member 1 (file-sync). Changetype ADDED Received an entry 803 from member 1 (file-sync). Changetype ADDED Received an entry 606 from member 1 (file-sync). Changetype ADDED Received an entry 842 from member 1 (file-sync). Changetype ADDED Received an entry 846 from member 1 (file-sync). Changetype ADDED Received an entry 827 from member 1 (file-sync). Changetype ADDED Received an entry 811 from member 1 (file-sync). Changetype ADDED Received an entry 813 from member 1 (file-sync). Changetype ADDED Received an entry 101 from member 1 (file-sync). Changetype ADDED element Url: Schemas validity error : Element 'Url', attribute 'Location': The attribute 'Location' is not allowed. Received an entry 814 from member 1 (file-sync). Changetype ADDED Received an entry 707 from member 1 (file-sync). Changetype ADDED Received an entry 847 from member 1 (file-sync). Changetype ADDED Received an entry 672 from member 1 (file-sync). Changetype ADDED Received an entry 674 from member 1 (file-sync). Changetype ADDED Received an entry 830 from member 1 (file-sync). Changetype ADDED Received an entry 192 from member 1 (file-sync). Changetype ADDED Received an entry 612 from member 1 (file-sync). Changetype ADDED Received an entry 710 from member 1 (file-sync). Changetype ADDED Received an entry 821 from member 1 (file-sync). Changetype ADDED Received an entry 769 from member 1 (file-sync). Changetype ADDED Received an entry 807 from member 1 (file-sync). Changetype ADDED Received an entry 826 from member 1 (file-sync). Changetype ADDED Received an entry 52 from member 1 (file-sync). Changetype ADDED Received an entry 820 from member 1 (file-sync). Changetype ADDED Received an entry 137 from member 1 (file-sync). Changetype ADDED Received an entry 777 from member 1 (file-sync). Changetype ADDED Received an entry 736 from member 1 (file-sync). Changetype ADDED Received an entry 812 from member 1 (file-sync). Changetype ADDED Received an entry 845 from member 1 (file-sync). Changetype ADDED Received an entry 770 from member 1 (file-sync). Changetype ADDED Received an entry 24 from member 1 (file-sync). Changetype ADDED Received an entry 828 from member 1 (file-sync). Changetype ADDED Received an entry 801 from member 1 (file-sync). Changetype ADDED Received an entry 771 from member 1 (file-sync). Changetype ADDED Received an entry 662 from member 1 (file-sync). Changetype ADDED Received an entry 791 from member 1 (file-sync). Changetype ADDED Received an entry 726 from member 1 (file-sync). Changetype ADDED Received an entry 620 from member 1 (file-sync). Changetype ADDED Received an entry 798 from member 1 (file-sync). Changetype ADDED Received an entry 654 from member 1 (file-sync). Changetype ADDED Received an entry 829 from member 1 (file-sync). Changetype ADDED Received an entry 767 from member 1 (file-sync). Changetype ADDED Received an entry 761 from member 1 (file-sync). Changetype ADDED Received an entry 120 from member 1 (file-sync). Changetype ADDED Received an entry 762 from member 1 (file-sync). Changetype ADDED Received an entry 806 from member 1 (file-sync). Changetype ADDED Received an entry 844 from member 1 (file-sync). Changetype ADDED Received an entry 690 from member 1 (file-sync). Changetype ADDED Received an entry 843 from member 1 (file-sync). Changetype ADDED Received an entry 638 from member 1 (file-sync). Changetype ADDED Received an entry 652 from member 1 (file-sync). Changetype ADDED Received an entry 608 from member 1 (file-sync). Changetype ADDED Received an entry 779 from member 1 (file-sync). Changetype ADDED Received an entry 193 from member 1 (file-sync). Changetype ADDED Received an entry 614 from member 1 (file-sync). Changetype ADDED Received an entry 794 from member 1 (file-sync). Changetype ADDED Received an entry 629 from member 1 (file-sync). Changetype ADDED Received an entry 815 from member 1 (file-sync). Changetype ADDED Received an entry 773 from member 1 (file-sync). Changetype ADDED Received an entry 822 from member 1 (file-sync). Changetype ADDED Received an entry 760 from member 1 (file-sync). Changetype ADDED Received an entry 194 from member 1 (file-sync). Changetype ADDED Received an entry 782 from member 1 (file-sync). Changetype ADDED Received an entry 763 from member 1 (file-sync). Changetype ADDED Received an entry 799 from member 1 (file-sync). Changetype ADDED Received an entry 666 from member 1 (file-sync). Changetype ADDED contact sink of member 1 of type file-sync just sent all changes Main sink of member 1 of type file-sync just sent all changes Received an entry 15 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 24 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 27 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 52 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 58 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 63 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 80 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 101 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 120 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 137 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 138 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 155 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 185 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 192 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 193 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 194 from member 2 (syncml-obex-client). C... [truncated message content] |
|
From: Michael B. <mic...@cm...> - 2008-02-12 11:39:33
Attachments:
smime.p7s
|
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 |
|
From: Simon J. <si...@jo...> - 2008-02-12 12:10:56
|
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 |
|
From: Michael B. <mic...@cm...> - 2008-02-12 14:18:47
Attachments:
smime.p7s
|
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 |
|
From: Daniel G. <dg...@su...> - 2008-02-12 15:26:27
|
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 |
|
From: Michael B. <mic...@cm...> - 2008-02-13 13:52:52
Attachments:
smime.p7s
|
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 |
|
From: Daniel G. <dg...@su...> - 2008-02-13 15:11:25
|
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 |
|
From: Michael B. <mic...@cm...> - 2008-02-13 15:25:37
Attachments:
smime.p7s
|
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 |
|
From: Daniel G. <dg...@su...> - 2008-02-13 15:43:39
|
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 |
|
From: Michael B. <mic...@cm...> - 2008-02-14 16:49:35
Attachments:
smime.p7s
|
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 |
|
From: Michael B. <mic...@cm...> - 2008-02-15 11:40:50
Attachments:
smime.p7s
|
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 |
|
From: Simon J. <si...@jo...> - 2008-02-19 21:46:15
|
Michael Bell <mic...@cm...> writes: > 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. Hi again. I'm not sure from the latest discussions whether my original problem is supposed to be fixed or not, but I just tried using the latest svn version of opensync, file-sync, syncml, vformat (but libsyncml 0.4.6 because libsyncml svn breaks directly with smlSafeFree errors) and I still get duplicates when syncing syncml-obex-client to file-sync. Slightly trimmed output as below. Should I expect any change in this yet? Forcing slow-syncing works relatively well, so I'll continue to do so. /Simon jas@mocca:~$ msynctool --sync e51-file Synchronizing group "e51-file" event sink of member 1 of type file-sync just connected contact sink of member 1 of type file-sync just connected Main sink of member 1 of type file-sync just connected Main sink of member 2 of type syncml-obex-client just connected ** (process:28882): WARNING **: The text/x-vcard property X-ANNIVERSARY is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-ASSISTANT is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-ASSISTANT-TEL is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-CHILDREN is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-CLASS is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-EPOCSECONDNAME is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-SIP is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-SPOUSE is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-WV-ID is not supported. event sink of member 2 of type syncml-obex-client just connected ** (process:28882): WARNING **: The text/x-vcard property X-ANNIVERSARY is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-ASSISTANT is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-ASSISTANT-TEL is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-CHILDREN is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-CLASS is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-EPOCSECONDNAME is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-SIP is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-SPOUSE is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-WV-ID is not supported. contact sink of member 2 of type syncml-obex-client just connected All clients connected or error Main sink of member 2 of type syncml-obex-client just sent all changes event sink of member 1 of type file-sync just sent all changes contact sink of member 1 of type file-sync just sent all changes Main sink of member 1 of type file-sync just sent all changes ** (process:28882): WARNING **: The text/x-vcard property X-ANNIVERSARY is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-ASSISTANT is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-ASSISTANT-TEL is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-CHILDREN is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-CLASS is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-EPOCSECONDNAME is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-SIP is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-SPOUSE is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-WV-ID is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-ANNIVERSARY is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-ASSISTANT is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-ASSISTANT-TEL is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-CHILDREN is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-CLASS is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-EPOCSECONDNAME is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-SIP is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-SPOUSE is not supported. ** (process:28882): WARNING **: The text/x-vcard property X-WV-ID is not supported. Received an entry 15 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 24 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 27 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 52 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 58 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 63 from member 2 (syncml-obex-client). Changetype ADDED ... Received an entry 840 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 841 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 842 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 843 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 844 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 845 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 846 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 847 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 848 from member 2 (syncml-obex-client). Changetype ADDED contact sink of member 2 of type syncml-obex-client just sent all changes event sink of member 2 of type syncml-obex-client just sent all changes All clients sent changes or error All conflicts have been reported Received an reply to our sync Received an reply to our sync contact sink of member 2 of type syncml-obex-client committed all changes. event sink of member 2 of type syncml-obex-client committed all changes. Main sink of member 2 of type syncml-obex-client committed all changes. Sent an entry 39-new to member 1 (file-sync). Changetype ADDED Sent an entry 40-new to member 1 (file-sync). Changetype ADDED Sent an entry 41-new to member 1 (file-sync). Changetype ADDED Sent an entry 42-new to member 1 (file-sync). Changetype ADDED Sent an entry 43-new to member 1 (file-sync). Changetype ADDED Sent an entry 44-new to member 1 (file-sync). Changetype ADDED Sent an entry 45-new to member 1 (file-sync). Changetype ADDED Sent an entry 46-new to member 1 (file-sync). Changetype ADDED Sent an entry 47-new to member 1 (file-sync). Changetype ADDED Sent an entry 48-new to member 1 (file-sync). Changetype ADDED Sent an entry 49-new to member 1 (file-sync). Changetype ADDED Sent an entry 50-new to member 1 (file-sync). Changetype ADDED Sent an entry 51-new to member 1 (file-sync). Changetype ADDED Sent an entry 52-new to member 1 (file-sync). Changetype ADDED Sent an entry 53-new to member 1 (file-sync). Changetype ADDED event sink of member 1 of type file-sync committed all changes. Sent an entry 15-new to member 1 (file-sync). Changetype ADDED Sent an entry 24-new to member 1 (file-sync). Changetype ADDED Sent an entry 27-new to member 1 (file-sync). Changetype ADDED Sent an entry 52-new to member 1 (file-sync). Changetype ADDED Sent an entry 58-new to member 1 (file-sync). Changetype ADDED Sent an entry 63-new to member 1 (file-sync). Changetype ADDED Sent an entry 80-new to member 1 (file-sync). Changetype ADDED Sent an entry 101-new to member 1 (file-sync). Changetype ADDED ... Sent an entry 839-new to member 1 (file-sync). Changetype ADDED Sent an entry 840-new to member 1 (file-sync). Changetype ADDED Sent an entry 841-new to member 1 (file-sync). Changetype ADDED Sent an entry 842-new to member 1 (file-sync). Changetype ADDED Sent an entry 843-new to member 1 (file-sync). Changetype ADDED Sent an entry 844-new to member 1 (file-sync). Changetype ADDED Sent an entry 845-new to member 1 (file-sync). Changetype ADDED Sent an entry 846-new to member 1 (file-sync). Changetype ADDED Sent an entry 847-new to member 1 (file-sync). Changetype ADDED Sent an entry 848-new to member 1 (file-sync). Changetype ADDED contact sink of member 1 of type file-sync committed all changes. Main sink of member 1 of type file-sync committed all changes. All clients have written event sink of member 2 of type syncml-obex-client reported sync done. contact sink of member 2 of type syncml-obex-client reported sync done. Main sink of member 2 of type syncml-obex-client reported sync done. event sink of member 1 of type file-sync reported sync done. contact sink of member 1 of type file-sync reported sync done. Main sink of member 1 of type file-sync reported sync done. All clients reported sync done The sync was successful event sink of member 1 of type file-sync just disconnected contact sink of member 1 of type file-sync just disconnected Main sink of member 1 of type file-sync just disconnected event sink of member 2 of type syncml-obex-client just disconnected contact sink of member 2 of type syncml-obex-client just disconnected Main sink of member 2 of type syncml-obex-client just disconnected All clients have disconnected jas@mocca:~$ |
|
From: Michael B. <mic...@cm...> - 2008-02-20 10:48:25
Attachments:
smime.p7s
|
Hi Simon, Simon Josefsson schrieb: > Hi again. I'm not sure from the latest discussions whether my original > problem is supposed to be fixed or not, but I just tried using the > latest svn version of opensync, file-sync, syncml, vformat (but > libsyncml 0.4.6 because libsyncml svn breaks directly with smlSafeFree > errors) and I still get duplicates when syncing syncml-obex-client to > file-sync. Slightly trimmed output as below. Should I expect any > change in this yet? The problem changed a little bit. My actual environment is libsyncml rev 383 and all other stuff is at rev 3179. I get no smlSafeFree errors. So if you get such errors then I need your traces or at minimum the last 20-100 lines of each log file (Thread-*). I can sync and the syncml part works very well. The problem is that the plugin signals SLOW-SYNC during connect but OpenSync or msynctool does not react. I don't know which part of the software should check for such an event. Perhaps Daniel can clarify this. If I know where I have to search then I can try to find the bug. So your problem is still some kind of open. We fixed the first bug and found another one :( 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 |
|
From: Michael B. <mic...@cm...> - 2008-02-21 14:25:28
Attachments:
smime.p7s
|
Michael Bell schrieb: > The problem is that the plugin signals SLOW-SYNC during connect but > OpenSync or msynctool does not react. I don't know which part of the > software should check for such an event. Perhaps Daniel can clarify > this. If I know where I have to search then I can try to find the bug. > > So your problem is still some kind of open. We fixed the first bug and > found another one :( The SLOW-SYNC is signalled now correctly. I described the bug a little bit more in detail on opensync-devel. The SLOW-SYNC issue is fixed with SVN version 3184 of opensync. More details can be found in the mail archive of the devel list. http://sourceforge.net/mailarchive/forum.php?thread_name=47BD87CE.2000501%40cms.hu-berlin.de&forum_name=opensync-devel If someone (especially Simon ;) ) could verify the change then this would be really nice. 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 |
|
From: Simon J. <si...@jo...> - 2008-02-21 14:53:16
|
Michael Bell <mic...@cm...> writes: > Michael Bell schrieb: > >> The problem is that the plugin signals SLOW-SYNC during connect but >> OpenSync or msynctool does not react. I don't know which part of the >> software should check for such an event. Perhaps Daniel can clarify >> this. If I know where I have to search then I can try to find the >> bug. >> >> So your problem is still some kind of open. We fixed the first bug >> and found another one :( > > The SLOW-SYNC is signalled now correctly. I described the bug a little > bit more in detail on opensync-devel. The SLOW-SYNC issue is fixed > with SVN version 3184 of opensync. More details can be found in the > mail archive of the devel list. > > http://sourceforge.net/mailarchive/forum.php?thread_name=47BD87CE.2000501%40cms.hu-berlin.de&forum_name=opensync-devel > > If someone (especially Simon ;) ) could verify the change then this > would be really nice. Thanks! I'm trying to test it, but I'm running into a separate problem: Running msynctool appears to works fine, but it doesn't seem to shut down properly. So it will always flag the sync as unclean, and the next sync will be a slow-sync. (That's why I can't test your patch: all my sync are slow-syncs!) A gdb backtrace is rather useless, see below. The trace logs doesn't grow when opensync is in this state. The tail of the first thread log is: [1203605481.656762] <<<<<<< smlTransportReceiveEvent: 1 [1203605481.656799] <<<<<<< smlTransportObexClientDisconnect [1203605481.656836] <<<<<<< smlTransportWorkerHandler [1203605481.656876] >>>>>>> smlTransportWorkerHandler(0xb0f1ded8, 0x807c480) [1203605481.656915] >>>>>>> smlTransportObexClientDisconnect(0x8079048, (nil)) [1203605481.656963] Disconnect loop 0 The tail of the second thread log file is: [1203605481.657388] <<<<<<< smlDsSessionDispatch() [1203605481.657424] >>>>>>> smlDsSessionDispatch(0x809b998) [1203605481.657458] recvChanges: (nil) changesCallback: 0xb7192fe0 [1203605481.657491] <<<<<<< smlDsSessionDispatch() [1203605481.657525] >>>>>>> smlManagerDispatch(0x807c278) [1203605481.657592] >>>>>>> _smlManagerEventFree(0x808dcc8) [1203605481.657628] <<<<<<< _smlManagerEventFree [1203605481.657663] <<<<<<< smlManagerDispatch [1203605481.679998] >>>>>>> smlManagerStop(0x807c278) [1203605481.680384] >>>>>>> smlThreadStop(0x8078170) Any ideas on how to track this down? I may be building opensync without debug symbols, which would explain the useless gdb stacktrace. I don't know cmake well, how do I turn off optimization and on debugging? /Simon (gdb) r --sync e51-file Starting program: /home/jas/bin/msynctool --sync e51-file [Thread debugging using libthread_db enabled] [New Thread 0xb7a366b0 (LWP 21424)] Synchronizing group "e51-file" [New Thread 0xb7053b90 (LWP 21427)] [Thread 0xb7053b90 (LWP 21427) exited] [New Thread 0xb6852b90 (LWP 21428)] [Thread 0xb6852b90 (LWP 21428) exited] The previous synchronization was unclean. Slow-syncing [New Thread 0xb6852b90 (LWP 21429)] [New Thread 0xb7053b90 (LWP 21430)] [New Thread 0xb6051b90 (LWP 21431)] [New Thread 0xb5850b90 (LWP 21432)] [New Thread 0xb504fb90 (LWP 21433)] [New Thread 0xb484eb90 (LWP 21434)] [New Thread 0xb404db90 (LWP 21435)] [New Thread 0xb384cb90 (LWP 21436)] [New Thread 0xb304bb90 (LWP 21437)] [New Thread 0xb284ab90 (LWP 21438)] [New Thread 0xb2049b90 (LWP 21439)] [New Thread 0xb1848b90 (LWP 21440)] event sink of member 1 of type file-sync just connected contact sink of member 1 of type file-sync just connected Main sink of member 1 of type file-sync just connected Main sink of member 2 of type syncml-obex-client just connected ... Received an entry 1126 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 1127 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 1128 from member 2 (syncml-obex-client). Changetype ADDED contact sink of member 2 of type syncml-obex-client just sent all changes All clients sent changes or error All conflicts have been reported Received an reply to our sync Received an reply to our sync Main sink of member 2 of type syncml-obex-client committed all changes. event sink of member 1 of type file-sync committed all changes. contact sink of member 1 of type file-sync committed all changes. Main sink of member 1 of type file-sync committed all changes. contact sink of member 2 of type syncml-obex-client committed all changes. event sink of member 2 of type syncml-obex-client committed all changes. All clients have written event sink of member 2 of type syncml-obex-client reported sync done. contact sink of member 2 of type syncml-obex-client reported sync done. Main sink of member 2 of type syncml-obex-client reported sync done. event sink of member 1 of type file-sync reported sync done. contact sink of member 1 of type file-sync reported sync done. Main sink of member 1 of type file-sync reported sync done. All clients reported sync done The sync was successful event sink of member 1 of type file-sync just disconnected contact sink of member 1 of type file-sync just disconnected Main sink of member 1 of type file-sync just disconnected event sink of member 2 of type syncml-obex-client just disconnected contact sink of member 2 of type syncml-obex-client just disconnected Main sink of member 2 of type syncml-obex-client just disconnected All clients have disconnected [Thread 0xb504fb90 (LWP 21433) exited] Program received signal SIGINT, Interrupt. [Switching to Thread 0xb7a366b0 (LWP 21424)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ae8aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb7dc97bd in pthread_cond_wait () from /lib/i686/cmov/libc.so.6 #3 0xb7e5b002 in ?? () from /usr/lib/libglib-2.0.so.0 #4 0x0806f0a0 in ?? () #5 0x0806b018 in ?? () #6 0xb7f5ca10 in ?? () #7 0xb7e2eff4 in ?? () from /lib/i686/cmov/libc.so.6 #8 0x0806b000 in ?? () #9 0xb7ee99c0 in ?? () from /usr/lib/libglib-2.0.so.0 #10 0x00000000 in ?? () (gdb) |
|
From: Michael B. <mic...@cm...> - 2008-02-22 09:04:48
Attachments:
smime.p7s
|
Simon Josefsson schrieb: > Running msynctool appears to works fine, but it doesn't seem to shut > down properly. So it will always flag the sync as unclean, and the next > sync will be a slow-sync. (That's why I can't test your patch: all my > sync are slow-syncs!) I have a similar problem actually but this is a very special bug: 1. I need at minimum one objtype which only sends DELETEs or nothing 2. I need at minimum one objtype which sends ADD or REPLACE The result is that the plugin expects two maps but receives only one map. I will prepare a fix today but I don't know if this fixes your problem. 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 |
|
From: Michael B. <mic...@cm...> - 2008-02-22 11:06:54
Attachments:
smime.p7s
|
Michael Bell schrieb: > Simon Josefsson schrieb: > >> Running msynctool appears to works fine, but it doesn't seem to shut >> down properly. So it will always flag the sync as unclean, and the next >> sync will be a slow-sync. (That's why I can't test your patch: all my >> sync are slow-syncs!) > > I have a similar problem actually but this is a very special bug: > > 1. I need at minimum one objtype which only sends DELETEs or nothing > 2. I need at minimum one objtype which sends ADD or REPLACE > > The result is that the plugin expects two maps but receives only one > map. I will prepare a fix today but I don't know if this fixes your > problem. I commited two patches. 1. I fixed libsyncml. The COMMITEDCHANGES event is now sent more reliable. (rev 385) 2. I replaced the commit code which depends on maps by more clean code relies on COMMITEDCHANGES event. (rev 3185) It works for me. This does not mean that your problem is fixed too :( 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 |
|
From: Arno K. <ar...@ak...> - 2008-03-02 17:25:32
|
I have the same problem with v0.22: sync works fine (evolution and syncml/obex) but after the message "All conflicts have been reported" msynctool won't shut down. I've looked into the sources but there seems to be no trivial way to backport your changes of r3185 into v0.22. Is there a way to further track this problem down? /Arno Michael Bell wrote: > > Michael Bell schrieb: >> Simon Josefsson schrieb: >> >>> Running msynctool appears to works fine, but it doesn't seem to shut >>> down properly. So it will always flag the sync as unclean, and the next >>> sync will be a slow-sync. (That's why I can't test your patch: all my >>> sync are slow-syncs!) >> >> I have a similar problem actually but this is a very special bug: >> >> 1. I need at minimum one objtype which only sends DELETEs or nothing >> 2. I need at minimum one objtype which sends ADD or REPLACE >> >> The result is that the plugin expects two maps but receives only one >> map. I will prepare a fix today but I don't know if this fixes your >> problem. > > I commited two patches. > > 1. I fixed libsyncml. The COMMITEDCHANGES event is now sent more > reliable. (rev 385) > > 2. I replaced the commit code which depends on maps by more clean code > relies on COMMITEDCHANGES event. (rev 3185) > > It works for me. This does not mean that your problem is fixed too :( > -- View this message in context: http://www.nabble.com/opensync%2Bisync-breaks-fast-syncing%2C-generates-dupes-tp15340473p15790551.html Sent from the Opensync - User mailing list archive at Nabble.com. |
|
From: Michael B. <mic...@cm...> - 2008-03-04 17:48:59
Attachments:
smime.p7s
|
Arno Klein schrieb: > I have the same problem with v0.22: sync works fine (evolution and > syncml/obex) but after the message "All conflicts have been reported" > msynctool won't shut down. I've looked into the sources but there seems to > be no trivial way to backport your changes of r3185 into v0.22. Is there a > way to further track this problem down? I have no idea in your case. I never tried v0.22 because I needed syncml over http and this is only available in the svn trunk area. Sorry 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 |
|
From: Simon J. <si...@jo...> - 2008-02-20 11:24:59
|
Michael Bell <mic...@cm...> writes: > Hi Simon, > > Simon Josefsson schrieb: > >> Hi again. I'm not sure from the latest discussions whether my original >> problem is supposed to be fixed or not, but I just tried using the >> latest svn version of opensync, file-sync, syncml, vformat (but >> libsyncml 0.4.6 because libsyncml svn breaks directly with smlSafeFree >> errors) and I still get duplicates when syncing syncml-obex-client to >> file-sync. Slightly trimmed output as below. Should I expect any >> change in this yet? > > The problem changed a little bit. My actual environment is libsyncml > rev 383 and all other stuff is at rev 3179. I get no smlSafeFree > errors. So if you get such errors then I need your traces or at > minimum the last 20-100 lines of each log file (Thread-*). I can sync > and the syncml part works very well. Hi Michael. I'm attaching the zip'ed logs in this mail. It dies pretty fast, here is the output: jas@mocca:/tmp/log$ time syncml-obex-client -b $MAC $CHANNEL --slow-sync text/x-vcard Contacts --wbxml --identifier "PC Suite" /home/jas/src/osync/libsyncml/libsyncml/sml_support.c:441:E:smlSafeFree: Assertion "*address" failed Aborted real 0m0.027s user 0m0.012s sys 0m0.012s jas@mocca:/tmp/log$ A gdb backtrace is: (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7b03f15 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7b05891 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb7efd855 in smlSafeFree () from /usr/local/lib/libsyncml.so.0 #4 0xb7efd88e in smlSafeCFree () from /usr/local/lib/libsyncml.so.0 #5 0xb7ef3269 in smlNotificationSend () from /usr/local/lib/libsyncml.so.0 #6 0x0804c440 in main () (gdb) I'll have to figure out how to build with debug information... > The problem is that the plugin signals SLOW-SYNC during connect but > OpenSync or msynctool does not react. I don't know which part of the > software should check for such an event. Perhaps Daniel can clarify > this. If I know where I have to search then I can try to find the bug. > > So your problem is still some kind of open. We fixed the first bug and > found another one :( Ok, no problem, and thanks for explaining. Forcing slow-syncing makes things work for me, although I suspect it is causing unnecessarily many merge dupes with the evolution plugin. But I can track down and report those separately. /Simon |
|
From: Simon J. <si...@jo...> - 2008-02-20 11:26:34
|
Simon Josefsson <si...@jo...> writes: > Hi Michael. I'm attaching the zip'ed logs in this mail. It dies pretty > fast, here is the output: The server rejected posts with zip attachments.. I placed it at: http://josefsson.org/tmp/smlsafefree.zip /Simon |
|
From: Michael B. <mic...@cm...> - 2008-02-12 14:09:52
Attachments:
smime.p7s
|
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 |
Thanks for helping keep SourceForge clean.
X