This patch also covers the case that the server needs to restart
because it has to run automatic syncs. The restart is implemented as a
brute-force execve() after removing output redirection, using the
original argv and env arrays (Restart class).
syncevo-dbus-server must restart after its installation was updated or removed.
Otherwise further sync attempts can fail. This was seen in practice when
SyncEvolution 1.0 was updated to 1.1 (Debian bug #617320): the in-memory daemon
used an old libsynthesis, but the on-disk XML files required more recent
libsynthesis features.
In general, *any* update of something loaded into memory should
trigger a shutdown or restart. A shutdown alone is okay when no
automatic sync scheduling is needed (auto sync off for all
configs). Clients will restart the daemon on demand. A restart is
needed otherwise because without it, automatic syncs would stop to
run.
This patch implements the shutdown part. Restart still needs to be
implemented. A 10 second delay is chosen between "file modified" and
"shut down". This is meant to ensure that a future restart does not
occur too soon (before all file changes are done). It's still a bit
racy, but a better solution would depend integration into
distro-specific hooks ("package update complete"), which is hard or
impossible (installation via "make install" or "tar xf").
This new feature is tested by test-dbus.py, including several corner
cases:
- testShutdown: files modified in regular intervals for a while
- testSession: a running session prevents the shutdown
- testSession2: same as testSession, with different timing
The Boost::intrusive_ptr works with GObject's own reference counting.
Defines in the global name space are needed for each GObject type to
tell Boost that the corresponding C struct is indeed a GObject.
The file notification class couples the C callbacks with
boost::function.
gcc 4.5.2 complained that a "case" value is not among those valid for
the "switch" enum. That's correct, the enum might be smaller than the
value. The root cause is an incorrect use of the enum type in the
callback: the signal itself is defined with gint.
SyncEvolution used to insist on having a template when creating a
config from scratch. This was meant to address typos like "--configure
sheduleworld". But when the command line contains enough information,
no template is needed.
The same logic was applied to configuring a source: if a source was not
among those defined by the template, configuring it was rejected as a
typo.
With this patch, there are two ways around these checks:
- --template none and/or
- specifying required properties on the command line
This patch also removes the special cases for "your SyncML server
account name/password". Username/password aren't always needed
(previous patch), nor are they always for a SyncML server anymore.
The value is a QtContacts URI for an address book, composed of
qtcontacts:<backend>:<URL encoded parameters>
Example values for "database":
qtcontacts:tracker:
qtcontacts:eds:source=local:/system
Fedora now includes a shared libgdbus under /usr/lib. This leads to a
conflict based on the *name* of the library, not just because of
*symbols* (which was resolved earlier).
Therefore this patch renames the version that SyncEvolution depends on
to libgdbusyncevo. All SyncEvolution patches were already sent
upstream, but it is uncertain whether libgdbus will be see further
releases. Patches to make SyncEvolution use a suitable system libgdbus
library are welcome.
The intention is that backends shall be able to bind additional
parameters to their implementation of the callbacks. The default
implementation used by most (all?) backends was adapted, so no
changes there are necessary.
This reverts commit ad608ca221.
vCard 3.0 has problems with other peers, for example Mobical. Better
stay conservative and use vCard 2.1 by default, as before. MemoToo
is dealt with by the previous commit which explicitly sets vCard 3.0
for MemoToo.
This patch fixes a problem that occured if:
* a peer was configured with a ifferently named template (--configure --template foo bar)
* and there was a config foo@xyz.
Then the nonsense error message "ERROR: template foo must not specify a context."
was printed (nonsense because "foo" does not specify a context) and the operation
failed.
The root cause was that SyncConfig::normalizeConfigString() expanded
the "foo" string to "foo@xyz" (desired when "foo" is a shorthand for
an existing config). This behavior now can be turned off with a
flag. The patch does that by replacing the bool parameter with a bit
field.
When committing a change and then calling make, the AC_INIT() version
changed and forced a complete rebuild of SyncEvolution, which was
inconvenient during normal development. Also happened as the date
changed, i.e., each morning.
Now the version change is ignored when gen-autotools.sh is invoked as
part of a "make" run, thus avoiding these extra rebuilds. This is how
SyncEvolution worked before revising the autotools file regeneration.
autogen.sh still updates the version and thus the nightly builds are
guaranteed to have accurate version information.
When SyncEvolution prefers vCard 3.0, additional properties like
NICKNAME work with Memotoo. This patch a) makes that the default
syncFormat in the Memotoo template and b) automatically sets it
in the "addressbook" source of all migrated configs which sync
with Memotoo (detected based on the syncURL).
The automatic config rewriting is possible because users upgrading
from the previous stable SyncEvolution release need to migrate their
configs anyway. Normally SyncEvolution does not modify configs like
this.
The reason for this change is that MemoToo works better
when vCard 3.0 is announced as the preferred format by
the client. Only then does it support the NICKNAME property,
for example.
The reason for keeping vCard 2.1 as the preferred format
where legacy servers. Not sure whether that still is an
issue. If it is, then these servers must have their
"syncFormat" property set explicitly in their templates
and existing configs.
Asking for .well-known wasn't leading to a redirect with Yahoo.
The RFC recommends trying the root path instead, which happens
to work.
A slight tweak was necessary to handle Yahoo's returning of
"/dav" properties when "/" is queried. With that it is possible
to unify the caldav/carddav code paths and remove the hard-coded
Yahoo paths.
The automatic service discovery was incomplete resp. faulty. Changes
necessary to make it work with Apple Calendar Server (both CalDAV and
CardDAV):
- properly detect redirects in PROPFIND
- send credentials as Basic authorization for PROPFIND, to
get "current-user-principal" properly set by server (<unauthenticated>
is returned by Apple Calendar Server otherwise)
- use the "current-user-principal" href to find calendar/addressbook-home-set
- extracting that href must be more intelligent to cope with
<DAV:href xmlns=...>
- avoid shared collections (we want the user's personal collection at this time)
Sending invalid credentials over HTTP was considered, but fails with
Apple Calendar Server if only Basic authentication is enabled, without
causing the server to send a challenge. Falling back to sending valid
credenticals would make the code more complex for a sitation which is
already insecure (plain text transmission of PIM data!) and thus
wasn't implemented.
See also:
http://tools.ietf.org/html/rfc4918#appendix-Ehttp://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0243.htmlhttp://thread.gmane.org/gmane.comp.web.webdav.neon.general/717/focus=719
ne_request_create() copies all parameters, but due to a bug in neon,
Digest authentication ended up using the original parameter. With
SyncEvolution freeing it before running the request, the ensuing
read-after-use error caused authentication problems with servers using
Digest authentication (Apple Calendar Server) or might even have
crashed.
Patch submitted and accepted upstream, but better work around it by
keeping the affected "method" string valid throughout the lifetime of
the request.
synthesis.pc (somewhat arbitrary) was bumped to 3.4 in the latest
source. SyncEvolution needs recent features in libsynthesis, so
check that libsynthesis is recent enough.
libneon 0.27 doesn't have ne_options2() and
ne_session_system_proxy(). ne_options2() is purely for debugging,
disabled in builds on old distros. ne_session_system_proxy() is needed
to enable the use of the system proxy settings. If a recent enough
libneon.so.27 is found at runtime (= one which has the function), then
it is called.
libical was contained in libecal in Ubuntu Hardy, at least the way how
SyncEvolution is compiled there. Thus use libecal-1.2 when libical is
not found. Also handle the different ical string allocation semantic
via the icalstrdup() wrapper.
Use a more specific error code instead STATUS_FATAL because otherwise
the UI cannot inform the user.
CalDAV sync attempt while offline => DNS SRV fails => STATUS_TRANSPORT_FAILURE.
No sync URL (as with Yahoo) + no domain in user name => DNS SRV impossible => STATUS_UNAUTHORIZED.
Yahoo CardDAV and CalDAV config only works with full domain (needed
for DNS SRV lookup). Add it if not present. If the resulting
username is invalid, we'll get a credentials error, as desired.
The RetryDuration value now defines the time after which the Neon
library is told to give up. Previously some Neon-internal default
was used.
Resending a pending request earlier still needs to be implemented.
As with SyncML over HTTP, a loss of network connectivity can lead
to a half-open TCP connection which the client cannot detect when
relying on TCP alone.
Non-ASCII characters and pictures get lost. X- Extensions can be
uploaded and are shown on the server, but are not returned by it.
These issues are all on the server side and it is unclear how to
work around them.
Therefore this patch disables contact support in the Yahoo! profile.
Can be enabled manually for testing purposes.
SyncEvolution itself is careful to not send a VEVENT with
RECURRENCE-ID unless the parent item is also in the Google Calendar.
If that is done, then the Google CalDAV server reports the item
in a REPORT, but cannot GET or DELETE it (404 error).
Because other clients might get the server into such a state (Android
client was mentioned), we must deal with it nevertheless. Retrieving
such an item uses a REPORT with UID filter as fallback. A
calendar-multiget had the same issue as a single GET. That code is in
the patch, but not enabled.
Deleting has no fallback. The item will simply remain on the server
and no error will be shown to users. Note that the same 404 error
might also occur in case of a concurrent delete by some other client,
so it makes sense to ignore this.
Just to be sure, flush stderr after running a neon operation and give
the OS a chance to process output redirection, if neon prints output
and redirection is active. It is uncertain whether this is really
necessary, but because it is off most of the time, it doesn't hurt
either.
The "error line" debug output from neon was recognized as potential
error by LogRedirect and shown to users at higher log levels. This patch
uses the new LogRedirect::addIgnoreError() to suppress this line.
A GET of a vCard returns data that seems to have gone through an
encoding step for transmission as part of HTML or XML: special
characters are replaced by entity codes. Worse, that step seems to be
done multiple times, leading to:
backslash &#92; single quote ' double quote "
instead of:
backslash \ single quote ' double quote "
Note the double encoding of \ as &#92; - really broken.
This patch works around that by unconditionally and repeatedly
replacing XML entities with the corresponding characters until no
entities are left in the item data. It would be nice to only do that
when such a broken server is detected, but detecting that is hard and
not implemented.
The downside obviously is that entities that the user (for whatever
reason) wants to have in his contact data will be replaced.
Enabled support for Yahoo! Contacts, by adding it to the configuration
created for Yahoo. Sending data to it requires suppressing empty
properties, which it doesn't seem to handle in all cases (empty
X-GENDER, for example).
When the syncURL setting is empty, the username is checked for
a domain part and that is used to find the CalDAV or CardDAV service.
The actual DNS lookup is done by invoking a shell script and wrapping
some common tools (host, dnslookup, adnshost). This approach avoids a)
keeps the feature optional (no hard library dependency) and b) is more
portable across platforms (availability of DNS resolver libraries varies,
sometimes the API for SRV lookup is poor).
No attempt is made to also find the right URL path via a TXT lookup,
because the services which this patch was tested with didn't seem to
support it.
Instead of the TXT lookup, .well-known paths are tried. But even that
didn't work with the services, so the search code in WebDAV still
needs to hard-code some well-known paths and tries them in a (now)
depth-first search. Services with full support for a redirect of these
known paths should work (but untested).
Previously, the credentials were read directly when instantiating
the ButeoBridge. That happened before the SSO patch in msyncd
looked up the real credentials. Now the credentials are retrieved
in startSync(), where they are available.
