On Tue, 2012-10-09 at 10:52 +0600, Ildar Mulyukov wrote: > On 08.10.2012 17:19:17, Patrick Ohly wrote: > > On Mon, 2012-10-08 at 16:41 +0600, Ildar Mulyukov wrote: > > $ syncevolution sync=? > [...] > > 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. > > em.. but sync-ui produces exactly sync=one-way-from-server . A bug?
The sync-ui cannot configure local sync. Did you set up the local sync manually and then change it in the sync-ui? This is similar to configuring a phone for direct syncing, which also has the "peerIsClient" flag set. The UI should be able to reverse the data flow direction in this case, but I have never tested it for local syncs. > > > 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. > > I still can't find a note how to _restore_ from this backup. From the UI: https://syncevolution.org/documentation/synchronization-guis Recovery operations If you have a problem with synchronization, you can recover your data by going through the ‘sync emergency’ process, from within the GUI. => https://syncevolution.org/wiki/sync-gui-data-recovery From the command line: https://syncevolution.org/documentation/syncevolution-usage Restore data from the automatic backups: syncevolution --restore <session directory> --before|--after [--dry-run] [--] <config> <source> ... ... syncevolution --restore <session directory> --before|--after [--dry-run] <config> <source> ... This restores local data from the backups made before or after a synchronization session. The --print-sessions command can be used to find these backups. The source(s) have to be listed explicitly. There is intentionally no default, because as with --remove there is no confirmation question. With --dry-run, the restore is only simulated. The session directory has to be specified explicitly with its path name (absolute or relative to current directory). It does not have to be one of the currently active log directories, as long as it contains the right database dumps for the selected sources. A restore tries to minimize the number of item changes (see section Item Changes and Data Changes). This means that items that are identical before and after the change will not be transmitted anew to the peer during the next synchronization. If the peer somehow needs to get a clean copy of all local items, then use --sync refresh-from-local in the next run. -- 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
