On Sun, 2011-06-26 at 18:14 +0200, Ove Kåven wrote:
> Den 26. juni 2011 16:59, skrev Patrick Ohly:
> >>  but it also seems to me that webdav/NeonCXX.cpp
> >> probably wouldn't honor those paths if I did.
> > 
> > ne_ssl_trust_default_ca() is called by SyncEvolution. If libeon itself
> > was compiled correctly, then it should find and use the default
> > certificates.
> 
> I guess it depends on what you mean by "correctly".

So that the app doesn't need to know the default. Figuring this out
once, in the system libraries (libsoup, libcurl, libneon) seems better
than expecting all app developers to know where certs are.

> Besides, the ability to override these
> paths from SyncEvolution would be nice anyway.

The problem is that the Neon API has no easy way to provide a path to
certs.

> > Can you send me the logs of downloading an event and updating it? Run
> > with loglevel=4 and send the "source-config" logs, those are the ones
> > showing the communication with the CalDAV server.
> 
> Done.

Thanks. It confirms that sending the artificial UID instead of the one
originally created on the CalDAV server is the root cause. It causes a
new item to be created instead of overwriting the existing one.

Attached is a patch which might solve the problem. It passes all of my
tests here, but I don't have a setup where the code is relevant. Please
let me know if it works for you.

-- 
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.

diff --git a/src/backends/webdav/CalDAVSource.cpp b/src/backends/webdav/CalDAVSource.cpp
index 047457b..962d59e 100644
--- a/src/backends/webdav/CalDAVSource.cpp
+++ b/src/backends/webdav/CalDAVSource.cpp
@@ -305,11 +305,22 @@ SubSyncSource::SubItemResult CalDAVSource::insertSubItem(const std::string &luid
          comp;
          comp = icalcomponent_get_next_component(newEvent->m_calendar, ICAL_VEVENT_COMPONENT)) {
         std::string subid = Event::getSubID(comp);
-        newEvent->m_UID = Event::getUID(comp);
-        if (newEvent->m_UID.empty()) {
-            // create new UID
-            newEvent->m_UID = UUID();
-            Event::setUID(comp, newEvent->m_UID);
+        EventCache::iterator it;
+        if (!luid.empty() &&
+            (it = m_cache.find(luid)) != m_cache.end()) {
+            // Additional sanity check: ensure that the expected UID is set.
+            // Necessary if the peer we synchronize with (aka the local
+            // data storage) doesn't support foreign UIDs. Maemo 5 calendar
+            // backend is one example.
+            Event::setUID(comp, it->second->m_UID);
+            newEvent->m_UID = it->second->m_UID;
+        } else {
+            newEvent->m_UID = Event::getUID(comp);
+            if (newEvent->m_UID.empty()) {
+                // create new UID
+                newEvent->m_UID = UUID();
+                Event::setUID(comp, newEvent->m_UID);
+            }
         }
         newEvent->m_sequence = Event::getSequence(comp);
         newEvent->m_subids.insert(subid);
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to