On Tue, 2012-05-22 at 11:53 +0200, Tom Kazimiers wrote: > Hi Patrick, > > On 22.05.2012 09:18, Patrick Ohly wrote: > > On Tue, 2012-05-22 at 00:53 +0200, Tom Kazimiers wrote: > >> On Sun, May 20, 2012 at 09:03:30PM +0200, Patrick Ohly wrote: > >>> On Sat, 2012-05-19 at 20:44 +0200, Tom Kazimiers wrote: > >>>> Now it seems I can update my local VCard data with the help of these > >>>> two commands: > >>>> > >>>> syncevolution funambol@default > >>>> syncevolution local@default > >>>> > >>>> With this I am able to update the VCard folder (here: > >>>> /home/tom/tmp/sync/vcard-dir). But I don't seem to be able to get changes > >>>> from the VCard files back to the SyncML server. All the changes I make to > >>>> the VCard files are not recognized by syncevolution (I try to sync with > >>>> the last two commands as well). > >>> > >>> What changes do you make to the vCard files? It should be possible to > >>> modify them (which must touch the last modified time stamp), add new > >>> files (file name doesn't matter) and delete some. > >> > >> It now works using the approach you suggested. I might had something > >> configured wrongly with my previous setup. However, it seems > >> syncevolution has a problem with different entries having the same > >> content. What happens is: a first synchronisation works without > >> problems and also --status calls show no changes. But after I change a > >> file and sync it I get new output from --status and sync calls: > >> > >> Data modified locally during synchronization: > >> *** addressbook *** > >> before sync | after > >> sync > >> removed during sync < > >> > >> > added during sync > >> > >> ------------------------------------------------------------------------------- > >> > >> > … > >> > >> > … > >> … > >> > >> ------------------------------------------------------------------------------- > >> > >> Every duplicate entry is listed there as locally modified during sync. > > > > Modified or duplicated? What you show are added entries. > > Sorry for not making me clear. A new initial sync shows no problems, the > local (file) database has (of course) no changes. Then I modify an entry > (one vCard file, say file "4") and sync it. The sync works fine, but > starting with that sync (even in the sync's own output, it looks like if > there is a --status call right after the syncing) I get the output > above.
I have an inkling what it could be. Are these duplicates byte-identical? The before/after comparisons are based on copying all items into the session directories. To save space, hard links are used between identical files. I suspect that this de-duplication is a bit too aggressive and fails to reproduce your duplicates, although they are still in your real data set. > >> did not change anything on those files, though. After having removed all > >> duplicates, it works without problems. I just was wondering about this > >> behaviour. > > > > It certainly doesn't look normal. Was this a normal two-way sync or a > > slow sync? During a slow sync it can happen that the SyncML server > > duplicates items. > > > > If it was a normal sync, then please send the syncevolution-log.html > > file of that session. You can find it in the directory listed by > > "syncevolution --print-sessions". > > It was a normal two-way sync. When I found out that the duplicates might > be a problem (and I don't want duplicates anyway), I deleted them. To > avoid searching for the correct log file and to see if the can be > reproduced I just started from scratch: removed all vCards, refreshed > from the server, copied a vCard file, named it differently and started > the sync. The same problem as described above occurred. I sent the log > file to you directly. Now every sync call shows the output until I > remove the duplicate. The log you sent seems to be a from a sync where no data was exchanged (not even the newly duplicated item). Never mind, let me test my theory. > >> Next I will look into getting this to work with abook. > > > > It's quite likely that at some point you will find that abook and the > > current file backend use different vCard flavors (= slightly different > > properties). > > > > The format of the file backend is a mixture of all known properties, > > defined in /usr/share/syncevolution/xml/datatypes/01vcard-profile.xml. > > The downside for your purpose is that the engine doesn't know about > > limitations in abook and/or won't format properties exactly as needed by > > abook. Not sure how much of an issue that will be. > > Yes, I already noticed that. The vCard files of syncevolution are more > detailed. I did't check if this is a problem for abook, though -- will > do so in the next days. It can be problem when SyncML servers expect SyncEvolution+abook to store more data than it really supports. Normally, a SyncML server only sends supported data and preserves unsupported data server-side. Well, good ones do that. SyncEvolution+Synthesis as server do it, in which case giving them wrong information about the locally supported data can cause data loss. Doesn't matter in simple cases where all involved peers support the same data. > > Or implement a backend which reads/writes abook directly... can you > > program in C++? > > I am able to program C++, yes. Implementing an abook backend would IMHO > be the cleanest solution. So if there are problems with abook reading > syncevolution's more detailed vCard files, I will have look at the > source code and see if I can add an abook backend. Maybe, I'll do this > even if abook has no problems with those files. So checking out the > developer documentation is one of the next steps. https://syncevolution.org/development has some pointers. Please don't hesitate to ask. I'm also on IRC (freenode, pohly). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
