Re: [SyncEvolution] Syncing to local machine
On Mon, 2010-05-10 at 18:32 +0100, Alec Leamas wrote:
On 05/10/2010 04:25 PM, Patrick Ohly wrote:
Thanks for a fast reply! Sorry I couldn't do the same for you...
> On Mon, 2010-05-10 at 14:27 +0100, Alec Leamas wrote:
>> So what I want to do
>> is to synchronize an evolution datasource against a file backend on the
>> same machine. I have created a client configuration for the server which
>> is a clone of the working client setups. Trying to sync, I get various
>> errors depending on using the 'daemon=no' option or not.
>>
> You definitely need --daemon=no. Otherwise you cannot have a client and
> server sync session in the same user account on the same machine. But
> with a proper setup and --daemon=no it should work.
>
> Can you quote the output of "--print-config -q" for the client and
> server config involved in this local sync?
>
files server.config and client.config at
ftp://mumin.dnsalias.net/pub/syncevo
The key problem is that client and server are apparently defined in the
same context and thus share the "evolutionsource" property of each
source. "context" = the settings which define a set of databases.
If you follow the server HOWTO, then your "@default" context (see
--print-config -q @default) defines the set of databases used by the
server as using the file backend ("type = file:...") and local files
("evolutionsource = file:///var/spool/sync/mk/...").
Now your client configuration was created in the same context and thus
uses the same "evolutionsource" properties, but with the Evolution
backends. As a result, both client and server read and write the same
directories, putting different items there. This explains the empty
VCALENDAR items.
To fix this, remove the client config. Then create it anew with
--configure --template SyncEvolution my-client-config@evolution
and the other sync properties set so that it works with the local
server. That should fix the problem.
--
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.