| Summary: | kmail2/akonadi handels maildir incorrect | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | Johannes Hirte <johannes.hirte> |
| Component: | Maildir Resource | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | Christoph.Pospiech, dilfridge, mail, marc+bugs, mikael.salson, pjetur, quazgar, t.zell |
| Priority: | NOR | ||
| Version: | 5.3.1 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | log file describing mail dir location and akonadi contents. | ||
Confirmed here (4.7.3), I guess this is purely an Akonadi issue. The fixes that are gone into 4.7.3 aren't enough. The mails are now stored in the right directory but only if I mark them manually. Otherwise they're still stored in the new/ dircetory without the right suffix. Mails imported with kmailcvt always remain in the new/ folder, no matter if they are marked as read or not. Still an issue with KDE SC 4.7.4. For example, I've fetched some mail via pop3. They were stored in the local inbox folder in the new/ directory. When reading them they were marked as read but stayed in the new/ direcotry. And this seems to be a problem. When I've tried to move them (in this case by marking them as spam manually), I got an error that this messages couldn't be moved. Marking them as unread and after this as read again, they were moved to the correct cur/ directory and now moving worked. Kmail2 is really unusable with this behavior. Surprisingly, with other filters it works. The mails that were moved by filters on fetch time into different folders are moved to the correct cur/ directory when I read them. A second test with inbox also worked. The mail is moved into the cur/ directory when read. When marking it as spam, the mail is moved into the designated spam folder and there into the new/ directory, where it stays. Also moving them from the spam folder to trash puts them into the new/ directory there and not into cur/. I don't know if it's the same bug, but for me, with 4.7.3 on Gentoo-64, importing from older Kmail directories did not create any files in the expected folders at all. I could verify with grep on a freshly created testuser, that the imported mails live _only_ inside the database (~/.local/share/akonadi/akonadi.db) and nowhere else on the file system. Created attachment 74363 [details]
log file describing mail dir location and akonadi contents.
Comment on attachment 74363 [details]
log file describing mail dir location and akonadi contents.
This log file shows that kmail2 (kmail 4.8.5 on Kubuntu 12.04.1) places a mail in the "new" sub directory after a move from sent-mail to another local mail folder. The mail was in the "cur" sub directory before. The akonadi data base keeps the correct flags ( \SEEN). So - akonadi appears to be OK, but kmail2 is broken.
BTW, as a work around, I wrote a perl script that renames the mail file and moves it from "new" to "cur", depending on the data stored in akonadi. To be on the safe side, you have to stop kmail and akonadi, but restart mysql to let the script run. Anyone interested please contact me. - Or should I place the script as an attachment to this bug report ? This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months. (In reply to Denis Kurz from comment #10) > This bug has only been reported for versions before 4.14, which have been > unsupported for at least two years now. Can anyone tell if this bug still > present? Something like this still happens to me with KMail 5.2.3: at least the majority of messages (both received and sent) moved from inbox to maildir folders appear to stay in the new/ directory. However, the names are correct afaict. A few examples from yesterday: $ ls -l --sort=time new/ | head -5 total 3520 -rw-r--r-- 1 marc marc 3642 sept. 24 20:29 1474741744.R502.tramontane:2,S -rw-r--r-- 1 marc marc 1003 sept. 24 19:35 1474738555.R217.tramontane:2,S -rw-r--r-- 1 marc marc 4891 sept. 24 17:57 1474732623.R961.tramontane:2,S -rw-r--r-- 1 marc marc 3057 sept. 24 17:38 1474731481.R842.tramontane:2,S *** Bug 328025 has been marked as a duplicate of this bug. *** Thanks for the feedback. *** Bug 303913 has been marked as a duplicate of this bug. *** |
Version: unspecified (using KDE 4.7.1) OS: Linux Kmail2 with akonadi stores all maildir-mails in the new/ folder without info-suffix. Wheres kmail1 stored mails in the correct directory (cur/ when processed) named like "1309962120.21613.toOhv:2,S", kmail2 names them like "{fd227731-e306-4442-8815-cfed25d16f60}". Also the naming is unconventional, it is not wrong as long the mails are put in the right directory with the correct suffix. Additional, when moving mails from an old kmaildir directory, some of them are marked as unread in the new maildir from kmail2. Also, when coping from a kmaildir, often only the headers where copied and the body was left empty. But I'm not sure, if this is related to the wrong naming/storing. Reproducible: Always Steps to Reproduce: store mails in a local maildir copy/move mails from an old kmaildir Actual Results: mails are stored at wrong place/with wrong name mails got copied incomplete and lose their read-state Expected Results: mails should be stored in the correct maildir-way, don't lose their read-state and got copied complete