attaching config.ini's for reference. Regards Sachin
On Mon, Jan 27, 2014 at 9:03 AM, Sachin Gupta <[email protected]> wrote: > + Forum > > > On Mon, Jan 27, 2014 at 9:03 AM, Sachin Gupta <[email protected]> wrote: > >> Hi Patrick, >> >> When running syncevolution, i am getting the following error: >> >> efault/sources/addressbook/config.ini: backend = file: not one of the >> valid values (virtual, calendar = events, addressbook = contacts, todo = >> tasks, memo = memos = notes, SQLite Address Book = sqlite-contacts = sqlite) >> >> With the same settings, i had installed syncevolution on another machine >> and it works fine there. Using the same config.ini files on the new machine. >> >> Please suggest what is missing here. >> >> Regards >> Sachin >> >> >
# Specifies the SyncEvolution backend and thus the # data which is synchronized by this source. Each # backend may support multiple databases (see 'database' # property), different formats inside that database (see # 'databaseFormat'), and different formats when talking to # the sync peer (see 'syncFormat' and 'forceSyncFormat'). # # A special 'virtual' backend combines several other # data sources and presents them as one set of items # to the peer. For example, Nokia phones typically # exchange tasks and events as part of one set of # calendar items. # # Right now such a virtual backend is limited to # combining one calendar source with events and one # task source. They have to be specified in the # ``database`` property, typically like this: # ``calendar,todo`` # # Different sources combined in one virtual source must # have a common format. As with other backends, # the preferred format can be influenced via the 'syncFormat' # attribute. # # Here's the full list of potentially supported backends, # valid 'backend' values for each of them, and possible # formats. Note that SyncEvolution installations usually # support only a subset of the backends; that's why e.g. # "addressbook" is unambiguous although there are multiple # address book backends. # # Currently active:: # # CalDAV # calendar events # CalDAVTodo # tasks # CalDAVJournal # memos # CardDAV # contacts # Evolution Address Book = Evolution Contacts = addressbook = contacts = evolution-contacts # vCard 2.1 = text/x-vcard # vCard 3.0 (default) = text/vcard # The later is the internal format of Evolution and preferred with # servers that support it. # Evolution Calendar = calendar = events = evolution-events # iCalendar 2.0 (default) = text/calendar # vCalendar 1.0 = text/x-vcalendar # Evolution Task List = Evolution Tasks = todo = tasks = evolution-tasks # iCalendar 2.0 (default) = text/calendar # vCalendar 1.0 = text/x-vcalendar # Evolution Memos = memo = memos = evolution-memos # plain text in UTF-8 (default) = text/plain # iCalendar 2.0 = text/calendar # vCalendar 1.0 = text/x-vcalendar # The later format is not tested because none of the # supported SyncML servers accepts it. # Files in one directory = file # Stores items in one directory as one file per item. # The directory is selected via database=[file://]<path>. # It will only be created if the prefix is given, otherwise # it must exist already. # The database format *must* be specified explicitly. It may be # different from the sync format, as long as there are # conversion rules (for example, vCard 2.1 <-> vCard 3.0). If # the sync format is empty, the database format is used. # Examples for databaseFormat + syncFormat: # text/plain + text/plain # text/x-vcard + text/vcard # text/calendar # Examples for evolutionsource: # /home/joe/datadir - directory must exist # file:///tmp/scratch - directory is created # # # Currently inactive:: # # ActiveSync Address Book = eas-contacts # ActiveSync Events = eas-events # ActiveSync Todos = eas-todos # ActiveSync Memos = eas-memos # mkcal = KCalExtended = calendar # 'database' normally is the name of a calendar # inside the default calendar storage. If it starts # with the 'SyncEvolution_Test_' prefix, it will be # created as needed, otherwise it must exist. # If it starts with the 'file://' prefix, the default # calendar in the specified SQLite storage file will # created (if needed) and used. # KDE Address Book = KDE Contacts = addressbook = contacts = kde-contacts # vCard 2.1 (default) = text/x-vcard # vCard 3.0 = text/vcard # The later is the internal format of KDE and preferred with # servers that support it. One such server is ScheduleWorld # together with the "card3" uri. # KDE Calendar = calendar = events = kde-events # iCalendar 2.0 (default) = text/calendar # vCalendar 1.0 = text/x-calendar # KDE Task List = KDE Tasks = todo = tasks = kde-tasks # iCalendar 2.0 (default) = text/calendar # vCalendar 1.0 = text/x-calendar # KDE Memos = memo = memos = kde-memos # plain text in UTF-8 (default) = text/plain # Maemo Calendar = calendar = events = maemo-events # iCalendar 2.0 (default) = text/calendar # vCalendar 1.0 = text/x-vcalendar # Maemo Tasks = todo = tasks = maemo-tasks # iCalendar 2.0 (default) = text/calendar # vCalendar 1.0 = text/x-vcalendar # Maemo Notes = memo = memos = notes = journal = maemo-notes # plain text in UTF-8 (default) = text/plain # iCalendar 2.0 = text/calendar # vCalendar 1.0 = text/x-vcalendar # QtContacts = addressbook = contacts = qt-contacts # vCard 3.0 = text/vcard # 'database' is specified via a QtContacts URI, which # consists of qtcontacts:<backend>:<URL encoded parameters>. # Examples: 'qtcontacts:tracker:' or 'qtcontacts:eds:source=local:/system' # SQLite Address Book = addressbook = contacts = sqlite-contacts # vCard 2.1 (default) = text/x-vcard # XMLRPC interface = xmlrpc # Data exchange is done via an XMLRPC interface on the datastore. #backend = file backend = file # Picks one of the backend's databases: # depending on the backend, one can set the name # and/or a unique identifier. # # Most backends have a default database, # like for example the system address book. # Not setting this property selects that default # database. # # If the backend is a virtual data source, # this field must contain comma seperated list of # sub datasources actually used to store data. # If your sub datastore has a comma in name, you # must prevent taht comma from being mistaken as the # separator by preceding it with a backslash, like this: # ``database=Source1PartA\,PartB,Source2\\Backslash`` # # To get a full list of available databases, # run ``syncevolution --print-databases``. The name # is printed in front of the colon, followed by # an identifier in brackets. Usually the name is unique and can be # used to reference the data source. The default # data source is marked with <default> at the end # of the line, if there is a default. database = file:///home/syncml/evol_store1/addressbook # Defines the data format to be used by the backend for its # own storage. Typically backends only support one format # and ignore this property, but for example the file backend # uses it. See the 'backend' property for more information. databaseFormat = text/vcard # authentication for backend data source; password can be specified # in multiple ways, see SyncML server password for details # # Warning: setting database user/password in cases where it is not # needed, as for example with local Evolution calendars and addressbooks, # can cause the Evolution backend to hang. # databaseUser = # databasePassword =
# 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. sync = two-way # this is appended to the server's URL to identify the # server's database; if unset, the source name is used as # fallback uri = card # When there are alternative formats for the same data, # each side of a sync offers all that it supports and marks one as # preferred. If set, this property overrides the format # that would normally be marked as preferred by a backend. # # Valid values depend on the backend. Here are some examples: # contacts - text/vcard = vCard 3.0 format # text/x-vcard = legacy vCard 2.1 format # calendar - text/calendar = iCalendar 2.0 format # text/x-vcalendar = legacy vCalendar 1.0 format # # Errors while starting to sync and parsing and/or storing # items on either client or server can be caused by a mismatch between # the sync format and uri at the peer. syncFormat = text/x-vcard # Some peers get confused when offered multiple choices # for the sync format or pick the less optimal one. # In such a case, setting this property enforces that the # preferred format specified with 'syncFormat' is # really used. forceSyncFormat = 1
_______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
