how can i tape the config command for both addressbook and calendar , i mean
uri ,type ...:
syncevolution --configure --sync-property logLevel=5 --source-property
calendar/uri="CalendarURI" --source-property calendar/type="text/calendar"
--source-property addressbook/uri="AdressbookURI" --source-property
addressbook/type="text/vcard" TemplatePortal (this command didn't work ).
how can i specify these sources and their config in the same command ?
On Mi, 2011-09-07 at 17:48 -0400, Ross Vandegrift wrote:
> On Wed, 2011-09-07 at 08:23 +0200, Patrick Ohly wrote:
> > **Warning:** in local sync, the sync config side acts as
> > server. Therefore the ``from-server`` variants
> > (``one-way-from-server``, ``refresh-from-server``) transfer data
> > from the sync config into the target config. The ``from-client``
> > variants transfer in the other direction, even if the target config
> > happens to access data on a remote server.
> > Hmm, it is not obvious that this also applies to syncing with devices
> > via Bluetooth.
> > This issue came up before, but there was no conclusion about the naming.
> > Should it be "refresh/one-way-from-peer" and
> > "refresh-the-peer/one-way-to-peer"? "refresh/one-way-from-local" and
> > "refresh/one-way-to-local"?
> I don't totally know what would've been obvious here - I don't think I
> have a good enough handle on things to give good input.
Let me phrase the question differently: if the options for "--sync" aka
"--source-property sync" had been named as follows, would that have
avoided the problem?
$ syncevolution --sync ?
Requests a certain synchronization mode when initiating a sync:
two-way = only send/receive changes since last sync
slow = exchange all items
refresh-from-remote = discard all local items and replace with
the items on the peer
refresh-from-local = discard all items on the peer and replace
with the local items
one-way-from-remote = transmit changes from peer
one-way-from-local = transmit local changes
disabled (or none) = synchronization disabled
refresh/one-way-from-server/client are also supported. Their use is
discouraged because the direction of the data transfer depends
on the role of the local side (can be server or client), which is
not always obvious.
When accepting a sync session in a SyncML server (HTTP server), only
sources with sync != disabled are made available to the client,
which chooses the final sync mode based on its own configuration.
When accepting a sync session in a SyncML client (local sync with
the server contacting SyncEvolution on a device), the sync mode
specified in the client is typically overridden by the server.
> And even if that doc snippet doesn't clearly refer to bluetooth, I still
> didn't read it...
I know, this warning isn't the right way of solving the problem. From
which documentation did you learn about the available sync modes?
> > > After syncing with the laptop, going back to the desktop works, but
> > > forces a slow sync. Repeating this seems to indicate that it always
> > > needs to slow sync calendar+todo, even if there are no changes. Is this
> > > expected behavior?
> > No. Does this only happen for calendar+todo, but not for addressbook?
> Hmm - I could reproduce this 100% last night, but not at all this
> afternoon. Syncs are normal when there's nothing to update, but I've
> run into another weird issue - data doesn't always sync through both
> Here's a case where I edit a contact on desktop, sync desktop<->phone,
Anchors from that sync:
[2011-09-07 17:33:55.029] Saved Last Remote Client Anchor='845', received <last> Remote Client Anchor='845' (must match for normal sync)
[2011-09-07 17:33:55.029] Received <next> Remote Client Anchor='845' (to be compared with <last> in NEXT session)
[2011-09-07 17:33:55.029] (Saved) Last Local Server Anchor='20110907T212942Z', (generated) Next Local Server Anchor='20110907T213355Z' (sent to client as <last>/<next> in <alert>)
> sync laptop<->phone. The edited Contact doesn't get sent to the laptop
> from the phone.
[2011-09-07 17:35:20.989] Saved Last Remote Client Anchor='847', received <last> Remote Client Anchor='847' (must match for normal sync)
[2011-09-07 17:35:20.989] Received <next> Remote Client Anchor='847' (to be compared with <last> in NEXT session)
[2011-09-07 17:35:20.989] (Saved) Last Local Server Anchor='20110907T213407Z', (generated) Next Local Server Anchor='20110907T213520Z' (sent to client as <last>/<next> in <alert>)
Why the phone doesn't send the contact is unknown. That's decided by the
> Then, I go back an sync on the desktop and it does a slow sync with no
> changes to either side.
[2011-09-07 17:35:35.325] Saved Last Remote Client Anchor='845', received <last> Remote Client Anchor='847' (must match for normal sync)
[2011-09-07 17:35:35.325] Received <next> Remote Client Anchor='847' (to be compared with <last> in NEXT session)
[2011-09-07 17:35:35.325] (Saved) Last Local Server Anchor='20110907T213355Z', (generated) Next Local Server Anchor='20110907T213535Z' (sent to client as <last>/<next> in <alert>)
[2011-09-07 17:35:35.325] (Saved) fResumeAlertCode = 0 (valid for >DS 1.2 only)
+–[2011-09-07 17:35:35.325] 'DSStateChange' - Datastore changes state, datastore=addressbook, oldstate=admin_ready, newstate=server_alerted [--][++] [->end] [->enclosing]
–[2011-09-07 17:35:35.325] End of 'DSStateChange' [->top] [->enclosing]
[2011-09-07 17:35:35.325] Alerted (code=200) for two-way Normal Sync
[2011-09-07 17:35:35.325] Switched to SlowSync because of Anchor mismatch or server-side user option
[2011-09-07 17:35:35.325] Created command 'Alert' (outgoing)
[2011-09-07 17:35:35.325] ALERTED from client for slow Sync
Note that the phone sent 845 as its next anchor in the first sync. Now
it sends 847 instead, which is wrong.
> Further subsequent syncs, even slow sync, doesn't ever sync this update
> to the laptop.
Just for the sake of completeness:
[2011-09-07 17:41:19.575] Saved Last Remote Client Anchor='847', received <last> Remote Client Anchor='847' (must match for normal sync)
[2011-09-07 17:41:19.575] Received <next> Remote Client Anchor='847' (to be compared with <last> in NEXT session)
[2011-09-07 17:41:19.575] (Saved) Last Local Server Anchor='20110907T213520Z', (generated) Next Local Server Anchor='20110907T214119Z' (sent to client as <last>/<next> in <alert>)
To me this looks like the phone doesn't properly distinguish among the
peers it syncs with. That pretty much breaks the sync topology where the
phone is the hub through which all data must pass.
Perhaps you can make your desktop that hub instead by synchronizing both
the laptop and the phone against it? USB Bluetooth dongles are cheap. Or
make the laptop the hub, synchronizing against the phone via Bluetooth
and against the desktop via HTTP
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.