Akonadi chokes on data with multiple resource type (I tested kcal, ical, icaldir, and vcarddir). Reproducible: Always Steps to Reproduce: 1. Create a new ical|icaldir|vcarddir resource within korganizer|kaddressbook 2. Point that resource to the ics or vcf files, click "OK" 3. Akonadi, mysqld and the korganizer|kaddressbook app are working (as well as Nepomuk) 4. All your contacts|events and tasks are shown in the application, that's great ! 5. Close korganizer|kaddressbook (perhaps you need to restart Akonadi too) 6. Open korganizer|kaddressbook again 7. You get only one error per resource, like this one : "AkonadiAgentServer(20469): akonadi_ical_resource: Can't find incidence with uid "f36a0552-a73e-4c0d-9945-e772057bfafe" ; item.id() = 521696 ItemRetrieverException : Unable to retrieve item from resource: <html>Invalid item retrieved</html>" Actual Results: As a result, you can no longer browser your precious data in korganizer|kaddressbook nor in akonadiconsole. Expected Results: If Akonadi can import data and show them once, don't choke on your own data. ### ICAL and ICALDIR resource ### In the log I get this error : "AkonadiAgentServer(20469): akonadi_ical_resource: Can't find incidence with uid "f36a0552-a73e-4c0d-9945-e772057bfafe" ; item.id() = 521696 ItemRetrieverException : Unable to retrieve item from resource: <html>Invalid item retrieved</html>". I found that this uid "f36a0552-a73e-4c0d-9945-e772057bfafe" is the uid of ___the very first row where data is null___, using this query : "SELECT remoteId, data FROM pimitemtable pit, parttable pt WHERE collectionid = 2617 -- this is my agenda collection id AND pit.id = pt.pimItemId AND data is not null;" ...and this uid exists in the std.ics file (`grep "f36a0552-a73e-4c0d-9945-e772057bfafe" std.ics` return a line where it find that uid, while querying the 'data' column in the akonadi database returns no such characters string. ### VCARDDIR resource ### With the vcarddir resource I get this same kind of error message (translated) : "Can't find contact information with uid "0bWSNqn4C6"". I found that this uid "0bWSNqn4C6" is the uid of ___the very first result where 'data' is not a vcard___ but a link to the file "0bWSNqn4C6_rX" into the folder ~/.local/share/akonadi/file_db_data/, and that file doesn't exists. That error message states that the uid 0bWSNqn4C6 can't be found, but I can with that query : "SELECT * FROM pimitemtable pit, parttable pt WHERE collectionid = 2683 AND pit.id = pt.pimItemId AND remoteId LIKE "%0bWSNqn4C6%";" ...and the file is physically present in the folder ~/.local/share/contacts (and is not empty). it seems like somehow Akonadi deletes files from ~/.local/share/akonadi/file_db_data/, but doesn't update the database.. Right now I'm trying to figure out if data that are entered via korganizer or kadressbook is lost before the bug arise, but I think I lost one or two tasks in that process.. Last but not least, I imported my data (ics and vcf) into another computer still on 4.9.5 for a new user, and everything went fine (and still is, which is the point of this bug report).
To complete my bug report, here is where and how I got the source files : Vcard files : I copied in a directory all the vcf files from a January backup when I was still using kde 4.9.5 (with that configuration, I couldn't use right click > addressbook properties on my addressbook. Somehow the resource was missing from the "Agents" tab, but kaddressbook worked great anyway). Then I created a vcarddir resource pointing to that directory. Ics files : I copied some files from a January backup when I was still using kde 4.9.5, and used that script (http://paste.ubuntu.com/5576063) to retrieve some events/tasks from a 2nd calendar (which was only into in the Akonadi database). I then imported this ics file into a kcal resource on korganizer 4.9.5, then exported it back into another std.ics file (just to be sure it was generated by korganizer, not by my script). Finally, I created an ical resource on kde 4.10 by importing that std.ics. As said in my previous post, korganizer showed all the tasks/events, but after a reboot, akonadi chocked on that resource.
Deleting ~/.local/share/akonadi, ~/.kde/share/apps/akonadi*, ~/.kde/share/config/akonadi* and ~/.config/akonadi, then creating new resources (ical for calendar, vcarddir for contacts) and reimporting the data leads to the same kind of error. The bug isn't specially triggered by restarting korganizer|kadressbook or akonadi as I did so many times before the problem shows up.
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present? If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.