On Mon, 2012-10-08 at 16:41 +0600, Ildar Mulyukov wrote:
> Hi,
> I've a simple "BACKUP" configuration (one of them):
> $ syncevolution --configure syncURL= username=$email
> backend=eas-contacts dumpData=0 printChanges=0 target-config@google-eas
> addressbook
> $ syncevolution --configure --template SyncEvolution_Client
> syncURL=local://@google-eas username= sync=one-way-from-server
> backend=file database=file:///tmp/Google_Contacts_backup_eas
> databaseFormat=text/vcard google-eas@Google_Contacts_backup_eas
> addressbook
>
> I thought that `sync=one-way-from-server` guarantee that the remote
> would keep untouched...
Check the documentation of the "sync" property, please. The "server" in
this case is not what you think it is:
======================================================================
$ syncevolution sync=?
'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 overriden by the server.
========================================================================
In your config, "server" is the local side, because it's the SyncML
server. I know, this is confusing, which is why the values were renamed.
What you want is "one-way-from-remote".
> 1st time it was true: contacts were pulled to local files. Great.
Did you accept to do a slow sync? That's the fallback when an
incremental sync cannot be done. See my recent discussion with Lukas on
the list about "one-way sync" and how "one-way-from-*" isn't really a
permanent one-way setup.
The solution for that is the "local-cache" sync mode (implemented in the
"pim" branch). The "local-cache" mode will keep a local copy of the data
in sync under all circumstances, including unexpected slow syncs.
> 2nd time after reboot and /tmp/Google_Contacts_backup_eas cleaned up I
> got most (131 of 135) of my contacts deleted. Sucks.
>
> The root reason for that must be the sync=two-way in target-config. Or
> maybe evolution-activesync misbehaved, I don't know.
No, the reason is elsewhere, see above.
> I'm lucky Google has a tiny time-machine behind the "Restore contacts"
> command.
SyncEvolution also has a builtin backup mechanism that you could have
used. "I feel lucky" also works outside of Google.
--
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
