Bug 255104

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.