Skip to content

SyncEvolution 0.8 beta 2: New File Backend

I have tagged SyncEvolution 0.8 beta 2 and uploaded a source snapshot. The biggest change in this snapshot was a reorganization of the source code and how it is compiled, with the intention of completely decoupling the core SyncEvolution from its backends. It is now possible to add a backend and compile it into a syncevolution binary without touching any source or build file in the core SyncEvolution.

There were only few user visible changes in the existing functionality, so I’m probably going to skip building binary packages:

  • To prevent accidental sync runs when a configuration change was intended, a new --run switch must be used when configuration properties are given on the command line. When neither --run nor --configure are specified, SyncEvolution prints an error and refuses to do anything.
  • Improved documentation for command line, in particular the synopsis.

File Backend

The most relevant improvement feature-wise is the addition of a new file backend: it stores each SyncML item as a separate file in a directory. The directory has to be specified via the database name, using [file://]<path> as format. The file:// prefix is optional, but the directory is only created if the prefix is used.

Change tracking is done via the file systems modification time stamp: editing a file treats it as modified and then sends it to the server in the next sync. Removing and adding files also works.

The local unique identifier for each item is its name in the directory. New files are created using a running count which is initialized based on the initial content of the directory as “highest existing number + 1″ and then incremented as needed to avoid collisions.

Although this sync source itself does not care about the content of each item/file, the server needs to know what each item sent to it contains and what items the source is able to receive. Therefore the “type” property for this source must contain a data format specified, including a version for it. Here are some examples:

  • type = file:text/vcard:3.0
  • type = file:text/plain:1.0

Some use cases for this new backend are:

  • verbatim backups/restores of data on SyncML server
  • copy data from a server, modify it manually or with scripts, send back changes

The file backend is going to be compiled into SyncEvolution by default. To use it:

  • create a new configuration with a new name and all sources disabled: --configure --sync-property username=your_account --sync-property password=your_password --source-property sync=none --template [scheduleworld|funambol|synthesis|...] new_config_name
  • create empty directories for each source that you want to synchronize, then enable them by invoking syncevolution once per source: --configure --source-property sync=two-way --source-property type=file:text/vcard:3.0 --source-property evolutionsource=your_addressbook_dir new_config_name addressbook
  • When you are done, sync normally: syncevolution new_config_name

{ 6 } Comments

  1. Drew Grimes | November 17, 2008 at 4:11 pm | Permalink

    Patrick – I’m using this to make a backup of my funambol data. Should I use source type = file:text/vcard:2.1?

    Thanks for all your hard work on this!

  2. Drew Grimes | November 17, 2008 at 5:06 pm | Permalink

    On occasion, when doing a sync with the file backend, the sync fails and the last line from the terminal is this:

    Trace/BPT trap

    Sometimes it occurs at the beginning of the process, sometimes it occurs later on after some of the records have been transfered from the server. Other times the sync completes successfully.

    I have all four sync sources set to refresh-from-server.

    I am working in Mac OS 10.4.11 on a G4 powerbook.

    BTW, is there a better place to post questions such as these?

  3. Drew Grimes | November 17, 2008 at 5:23 pm | Permalink

    update – the same problem is occurring with the regular sync configuration for the Mac address book only. Perhaps it’s an issue with version 0.8.1? I hadn’t had this problem with 0.7; I didn’t attempt to sync normally with 0.8.1 before trying the file backend.

  4. Patrick Ohly | November 17, 2008 at 11:44 pm | Permalink

    Yes, type = file:text/vcard:2.1 is correct for Funambol. It wouldn’t make a difference right now though (type is determined by the URI).

    I have no idea where the Trace/BPT trap comes from in 0.8.1. Do you have a debugger (gdb or XCode) installed and can you generate a stack backtrace? With gdb you would run “gdb syncevolution”, then “run server_name”, followed by “thread apply all bt” after the error occurred.

    You can report this bug in the bug tracker http://

  5. Drew Grimes | November 18, 2008 at 4:50 am | Permalink

    I do have XCode installed, though I don’t really know how to use it. Is there a quick instruction you could give me for debugging with xcode?

    I’ve created a new artifact in the bug tracker for this.

    Thanks Patrick!

  6. Patrick Ohly | November 19, 2008 at 7:20 pm | Permalink

    Sorry, I have no experience with XCode myself. I’ll try it out as soon as I can, then reply in the bug tracker.

{ 1 } Trackback

  1. [...] A while back I added support for synchronizing files in a specific directory. Each file must contain a complete item, like for example a VCALENDAR with a VEVENT inside. These instructions in the ScheduleWorld Wiki describe how SyncEvolution’s file backend can be hooked up with KDE4’s PIM. [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *