Hi, On 22.05.2012 13:02, Patrick Ohly wrote: > 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?
Yes, they are. > 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. Sounds reasonable. If you have a commit to try out for me, I could give you some feedback whether that was the problem. >>>> 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. True, I thought this would be alright as the output indicating those local changes are produced by this sync, too. If you want I could send you the initial sync log as well. >>>> 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). Thanks, I'll have a look at it. Cheers, Tom
signature.asc
Description: OpenPGP digital signature
_______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
