Version: 2.0 beta1 (using KDE 4.5.2) OS: Linux After switching my user from KDE 4.4 to KDE 4.5 (including kdepim 4.5) I can no longer start KMail. It fails with Could not create collection Reproducible: Always Steps to Reproduce: Compiled and installed kde 4.5 (including kdepim 4.5). Switching my KDE 4.4 user to KDE 4.5 results in a startup failure for kmail. Akonadi diagnostic shows no problems, but the error log states the following on KDE startup: [akonadiserver] Error during executing query "INSERT INTO CollectionTable (remoteId, remoteRevision, name, parentId, resourceId, cachePolicyInherit) VALUES (:0, :1, :2, :3, :4, :5)" : "Duplicate entry '134-outbox' for key 'parentAndNameIndex' QMYSQL3: Unable to execute statement" [akonadiserver] Error during insertion into table "CollectionTable" "Duplicate entry '134-outbox' for key 'parentAndNameIndex' QMYSQL3: Unable to execute statement" [/opt/kde4.5/bin/akonadi_maildispatcher_agent] akonadi_maildispatcher_agent(26031)/libakonadi Akonadi::SpecialCollectionsRequestJobPrivate::collectionCreateResult: Failed CollectionCreateJob. "Unbekannter Fehler. (Could not create collection)" [/opt/kde4.5/bin/akonadi_maildispatcher_agent] akonadi_maildispatcher_agent(26031) OutboxQueue::Private::localFoldersRequestResult: Failed to get outbox folder. Start Kmail. and wait for the error message box. Actual Results: Akonadi diagnostic shows no problems, but the error log states the following on KDE startup: [akonadiserver] Error during executing query "INSERT INTO CollectionTable (remoteId, remoteRevision, name, parentId, resourceId, cachePolicyInherit) VALUES (:0, :1, :2, :3, :4, :5)" : "Duplicate entry '134-outbox' for key 'parentAndNameIndex' QMYSQL3: Unable to execute statement" [akonadiserver] Error during insertion into table "CollectionTable" "Duplicate entry '134-outbox' for key 'parentAndNameIndex' QMYSQL3: Unable to execute statement" [/opt/kde4.5/bin/akonadi_maildispatcher_agent] akonadi_maildispatcher_agent(26031)/libakonadi Akonadi::SpecialCollectionsRequestJobPrivate::collectionCreateResult: Failed CollectionCreateJob. "Unbekannter Fehler. (Could not create collection)" [/opt/kde4.5/bin/akonadi_maildispatcher_agent] akonadi_maildispatcher_agent(26031) OutboxQueue::Private::localFoldersRequestResult: Failed to get outbox folder. Expected Results: KMail should simply start up and work like before. Updating my existing kde 4.4 kdepim to 4.5 results in an automatic conversion to the new nepomuk based akonadi format (whatever this means). There were no error messages during the conversion, but starting KMail (oder Kontact) always fails now. I am not sure if this is in fact only akonadi related and no error of kmail 2. Perhaps the conversion to the new nepomuk format failed somehow.
Created attachment 52824 [details] KDE 4.5 startup log showing akonadi and kmail error output. The attached log shows the startup of my KDE 4.5 following the start of kmail.
Cannot see in 4.7.1, please reopen if you still run into it.
Created attachment 84708 [details] kontact startup log Please reopen, I encounter the same issue in KDE 4.12.0/4.11.5.
P.S: On the last boot I deleted the folder "trash" from the ${IMAP_HOST2} account. I then immediately tried to create it again, but Kontact did not let me, claiming a resource/folder of that name already exists. I was able to create the folder after restarting Kontact. The error message now is: Im E-Mail-Programm ist ein schwerwiegender Fehler aufgetreten. Das Programm wird beendet. Die Fehlermeldung lautet: Could not create collection trash resourceId: 11
P.P.S: I have setup my Dovecot 2.2 server to automatically create and subscribe to that folder: mailbox trash { special_use = \Trash auto = subscribe } Thus I cannot actually delete it. Maybe this is what creates a hickup within Kontact/Akonadi.
In the job tracker of AkonadiConsole, I see for the kontact-123456789 client: SpecialMailCollectionsRequestJob, Failed: Could not create collection trash resourceId: 11 |-DefaultResourceJob, Ended | |-CollectionFetchJob, Ended (CollectionId 0) | \-CollectionFetchJob, Ended (CollectionId 0) \-CollectionCreateJob, Running
Created attachment 84711 [details] akonadi log I ran akonadictl restart on a console and then started kontact. This is the resulting log.
mysql shows the following (excerpt): use akonadi; select * from collectiontable; | id | remoteId | remoteRevision | name | parentId | resourceId | subscribed | cachePolicyInherit | cachePolicyCheck Interval | cachePolicyCacheTimeout | cachePolicySyncOnDemand | cachePolicyLocalParts | queryString | queryLanguage | isVirtual | | 2 | /home/${USER}/.local/share/local-mail | | Lokale Ordner | NULL | 11 | 1 | 0 | -1 | 1 | 1 | ENVELOPE | NULL | NULL | 0 | | 13 | imap://${USER}@${IMAP_HOST2}/ | | ${IMAP_HOST2} | NULL | 8 | 1 | 0 | 5 | -1 | 1 | ENVELOPE HEAD RFC822 | NULL | NULL | 0 | | 1352 | trash | 0 | trash | 2 | 11 | 1 | 1 | -1 | -1 | 0 | NULL | NULL | NULL | 0 | | 1370 | /trash | | trash | 13 | 8 | 1 | 1 | -1 | -1 | 0 | NULL | NULL | NULL | 0 | So it appears that it does not create the trash folder in the IMAP resource as I initially expected, but in the local resource instead.
(In reply to comment #8) > So it appears that it does not create the trash folder in the IMAP resource > as I initially expected, but in the local resource instead. That was the issue. Deleting the Local Folder from AkonadiConsole (which made Akonadi automatically create a new maildir resource immediately), worked around the problem. I hope this is enough information to track down the problem. within Akonadi and/or Kontact.
(In reply to comment #9) > (In reply to comment #8) > > So it appears that it does not create the trash folder in the IMAP resource > > as I initially expected, but in the local resource instead. > > That was the issue. Deleting the Local Folder from AkonadiConsole (which > made Akonadi automatically create a new maildir resource immediately), > worked around the problem. Oups, now akonadi spams to the console it was started from: akonadi_maildispatcher_agent(4497)/libakonadi: Resource id's don't match: "akonadi_maildir_resource_1" "akonadi_maildir_resource_0" I assume that is a different bug? I am unsure what exactly the cause is, since everything seems to have been screwed up before already...
I am observing this issue in kde 4.11.5 (Fedora 20), so this bug exists and should not be closed. Should I submit a new bug (while this one have not been properly investigated :))? Kmail message: The Email program encountered a fatal error and will terminate now. The error was: Could not create collection outbox resourceId: 17
[dez@dezj tests]$ kmail kmail2(908)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/home/denis/.kde/share/apps/messageviewer/themes/" kmail2(908)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/usr/share/kde4/apps/messageviewer/themes/" kmail2(908)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/home/denis/.kde/share/apps/messageviewer" kmail2(908)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/usr/share/kde4/apps/messageviewer" loaded the Generic plugin [dez@dezj tests]$ kmail2(908)/libakonadi Akonadi::SpecialCollectionsRequestJob::slotResult: Failed SpecialCollectionsRequestJob::slotResult "Could not create collection outbox resourceId: 17" kmail2(908) MailCommon::Kernel::emergencyExit: "The Email program encountered a fatal error and will terminate now. The error was: Could not create collection outbox resourceId: 17"
This bug also just manifested itself for me, on KDE 4.13.1. I am pretty sure that it has to do with me setting the trash folder of an IMAP account to some folder other than the default one in the Local Folders. Luckily, I found a workaround for this bug at the KDE forums [1]. More specifically, this post [2] gave what turned out to be the solution for me. I opened Akonadi console and deleted the Local Folders agent in the Agents tab. After that, I logged out and back in again to find KMail starting without any problems again. Also, the folder I had marked to be the trash folder in the IMAP account was still marked, so no information was lost in that regard. Since this bug was the #1 hit on Google for me, I hope this solution helps some others. Cheers! [1]: https://forum.kde.org/viewtopic.php?f=215&t=120777 [2]: https://forum.kde.org/viewtopic.php?f=215&t=120777#p308518
(In reply to Thom C. from comment #13) > > I opened Akonadi console and deleted the Local Folders agent in the Agents > tab. Thanks that worked. (Hit by this bug on 4.12.5 after changing Trash defaults and then having X xcrash in mid-session.) This bug should be reopened.
I ran into the same issue with a new install of KDE with 4.14.3. The proposed work-around via akonadiconsole worked for me.
I run into this same issue in KMail 4.14.6. This bug should not be marked as "resolved worksforme" since it is not resolved and causes problems to users. We cannot expect normal users to browse through bug reports in order to be able to use their software, and this bug is a show stopper since it prevents people from starting the software.
I also encounter this bug on Kubuntu 15.10 with Kmail 5.0.2 after moving my Trash from local folders to my IMAP trash folder.
I confirm this bug is still present. It appeared once I added new IMAP account and redirect the trash folders Kubuntu 14.04LTS Qt : 4.8.6 Plate-forme de développement de KDE : 4.13.3 KMail : 4.13.3
*** This bug has been confirmed by popular vote. ***
Bug is still present in KDE Applications 16.12.1 Workaround: Rename ~/.local/share/akonadi_maildir_resource_0/trash to e.g. /home/AW/.local/share/akonadi_maildir_resource_0/trash-old However, this bug has been around for _seven_ years!
Created attachment 108604 [details] a
Comment on attachment 108604 [details] a I'm getting this bug for 2 months now. Everything is latest as of today, in arch.
See bug 339214.