Known Issues

ObjectWeb #num refers to the Funambol issue tracker, which is used to track issues in the Funambol C++ client library and server. Other issues are known limitations in certain servers or Evolution versions. Unless mentioned otherwise, problems were observed in the listed version, but might also affect other versions.

In addition to this list, there is also a blog article which explains how synchronization works and what pitfalls exist. Recommended reading, if you have the time.

Different Evolution releases

Different Evolution releases are often not binary compatible. Therefore, SyncEvolution might have to be recompiled or updated, when switching between Evolution releases. The table in the Evolution compatibility section summarizes that and shows which releases precompiled binaries are provided for.

Warnings about missing libe* libraries are caused by an incompatibility between the syncevolution binary and the installed Evolution:

syncevolution: error while loading shared libraries: libebook-1.2.so.9: cannot open shared object file: No such file or directory

A less obvious incompatibility is caused by having the right libraries installed (perhaps after a distribution upgrade), while running a different Evolution. For example, the Evolution libraries from 2.6.x failed to work after an upgrade to Evolution 2.12, as follows (for details, see SF issue #1818718):

Removing a field

Removing a field, and then synchronizing with a Funambol server, will not remove that field on the server. The server will preserve the old value instead. Other servers might do the same.

This is necessary because a SyncML server cannot distinguish between removed fields and fields that a client does not store. To avoid losing data, when copying back items from a less capable client, the server preserves missing fields, even in a situation where the field was intentionally removed on the client.

The workaround for this conceptual problem is to never clean (= remove) a field. Better to fill it, for example with a single space.

Changing the type of, for example, a phone number

Changing the type of, for example, a phone number might not be detected by a SyncML server as changing the type, but rather as adding a new number. Because removing fields does not work, the server will keep the number with the old type.

Evolution GUI

When importing or updating a contact from the server, some telephone numbers might only be displayed in the contact summary after editing the contact once. Evolution 2.0.4 till 2.6.3, ContactSync::testMerge test. Starting with SyncEvolution 0.4, this is solved by modifying the contact in the same way as the internal editor does. If it still fails, the server might send phone numbers without setting their type correctly.

End date of recurring events

Older versions of Evolution (like 2.0.4) use an Evolution-specific extension of iCalendar 2.0 to mark the end data of a recurring event. SyncEvolution makes no attempts to translate that into something that servers like eGroupware understand . This will not be added because this problem can be avoided by updating Evolution. Since at least version 2.6.3, Evolution uses the normal end date parameter.

Removing a recurrence not synchronized

The file backend of Evolution Data Server <= 2.27.5 does not increase the LAST-MODIFIED property of a recurring event when removing specific recurrences, therefore SyncEvolution does not recognize the event as modified and thus does not update the server. A fix for this is expected to be included in Evolution 2.28.

Adding timezone to Evolution

Evolution has a problem when SyncEvolution receives a calendar event with a new timezone definition. SyncEvolution adds the definition to the Evolution database, but an already running Evolution crashes, when trying to open the new event. Restarting Evolution solves that problem. The problem was found in Evolution 2.0.4, but has been resolved since.

Creating new address book

In Evolution, an address book has to be viewed once in Evolution after creating it (observed in 2.0.4). Otherwise, accessing it in SyncEvolution fails with:

gconf required

In an installation of Evolution, the libraries used by SyncEvolution crash unless the gconfd was started earlier, for instance, by logging into GNOME or running the Evolution GUI (observed with 2.4.2.1)