Bug 255104

Summary: KMail fails to start with: Could not create collection
Product: [Applications] kmail2 Reporter: Stephan Johach <hunsum>
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED WORKSFORME    
Severity: crash CC: amantia, bugs.kde.org, cookie170, denis.zalewsky, heri+kde, hsp, jan, jeckferson, josef64, robert, td_safemail-linux, thom.castermans
Priority: NOR    
Version: 2.0.90   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: KDE 4.5 startup log showing akonadi and kmail error output.
kontact startup log
akonadi log
a

Description Stephan Johach 2010-10-24 13:48:16 UTC
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.
Comment 1 Stephan Johach 2010-10-24 13:54:20 UTC
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.
Comment 2 András Manţia 2011-09-18 08:39:32 UTC
Cannot see in 4.7.1, please reopen if you still run into it.
Comment 3 Dennis Schridde 2014-01-17 20:40:18 UTC
Created attachment 84708 [details]
kontact startup log

Please reopen, I encounter the same issue in KDE 4.12.0/4.11.5.
Comment 4 Dennis Schridde 2014-01-17 20:44:06 UTC
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
Comment 5 Dennis Schridde 2014-01-17 20:47:30 UTC
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.
Comment 6 Dennis Schridde 2014-01-17 20:57:45 UTC
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
Comment 7 Dennis Schridde 2014-01-17 21:02:00 UTC
Created attachment 84711 [details]
akonadi log

I ran akonadictl restart on a console and then started kontact. This is the resulting log.
Comment 8 Dennis Schridde 2014-01-17 21:10:37 UTC
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.
Comment 9 Dennis Schridde 2014-01-17 21:14:56 UTC
(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.
Comment 10 Dennis Schridde 2014-01-17 21:23:39 UTC
(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...
Comment 11 Denis Zalewsky 2014-05-16 07:54:36 UTC
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
Comment 12 Denis Zalewsky 2014-05-16 07:55:57 UTC
[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"
Comment 13 Thom C. 2014-07-23 06:19:40 UTC
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
Comment 14 Erik Quaeghebeur 2014-11-20 11:24:57 UTC
(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.
Comment 15 Robert Riemann 2014-12-28 20:58:44 UTC
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.
Comment 16 daniel 2015-10-18 19:36:21 UTC
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.
Comment 17 Jan Wiele 2015-12-08 11:38:35 UTC
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.
Comment 18 Fnx 2016-02-29 22:36:41 UTC
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
Comment 19 Thomas 2016-03-12 18:13:27 UTC
*** This bug has been confirmed by popular vote. ***
Comment 20 Alexander 2017-02-07 19:40:43 UTC
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!
Comment 21 kts 2017-10-28 11:39:18 UTC
Created attachment 108604 [details]
a
Comment 22 kts 2017-10-28 11:40:29 UTC
Comment on attachment 108604 [details]
a

I'm getting this bug for 2 months now. Everything is latest as of today, in arch.
Comment 23 Christoph Feck 2017-11-15 20:13:56 UTC
See bug 339214.