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
>>> 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. Every duplicate in the data base gets marked as "added during
sync". So if there are two identical vCard files (say "7" and
of them (e.g. "7") will show up as "added during sync". These are not
necessarily the entries that one has been editing before. The duplicates
have been there before and I don't think they are produced by
syncevolution, gotta check this tonight. This needs some more
investigation on my side.
> did not change anything on those files, though. After having removed all
> duplicates, it works without problems. I just was wondering about this
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
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
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.
>> It will be easier to test this when syncing Funambol directly
>> your @local file source:
>> syncevolution --configure \
>> --template funambol \
>> funambol@local \
>> 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.
Alright, thanks. It's getting clearer :-).
> 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
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.
As a first step you could modify that file directly, ignoring
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.
Thanks for the hints. I will look into this if there are problems.
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.