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. > I > 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 will be easier to test this when syncing Funambol directly against > > your @local file source: > > syncevolution --configure \ > > --template funambol \ > > funambol@local \ > > addressbook > > > > Strictly speaking, the "--template" parameter is redundant because > > SyncEvolution would guess the right template based on the config name. > > > > Now you can synchronize with "syncevolution funambol@local" and check > > for changes with "syncevolution --status funambol@local". The latter > > command will tell you which changes in the file address book > > SyncEvolution sees, without changing anything. > > Thanks a lot! This makes the configuration much easier. So this > configuration adds a new peer (funambol) to the context "@local", > doesn't it? And because the @local context has a file backend the peer's > data gets stored in vCards? Correct. All peers in the same context share the same database settings. > 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. As a first step you could modify that file directly, ignoring anything with "rule=KDE". A cleaner solution would be needed to include your changes back into SyncEvolution, for example by adding more conditional sections and making the file backend format more configurable. Or implement a backend which reads/writes abook directly... can you program in C++? -- 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 SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
