I've opened my old kmaildir directory from kmail with kmail2 and tried to copy over some of the mails. Where the old mails where stored maildir-like in the cur/ directory, named like 1299590689.30198.qVwo9 or 1299590694.30198.mLUTH:2,S, kmail2 now stores them permanently in the new/ directory, named like {00d63972-d24c-4870-be74-c18bcad89914}. I've also noticed that sometimes only the headers where copied and the complete body was missing. kmail2 is unusable this way. I'm using akonadi with the sqlite backend. Reproducible: Always
Can't do much about this here unfortunately. Please file a bug at bugs.kde.org and add the link in the URL field here. This way we can keep track of the progress.
Tested with the mysql akonadi-backend and still the same problem. Bug is opened upstream.
I vaguely remember some upstream patch about this, but it seems that has not even made it into the upstream bug. Needs research.
Fixed in 4.7.2; you should mark your upstream report as duplicate of one of these... commit dd2619f53039f8d6a3b0dee0f37b6c89e5f2da44 Author: Andras Mantia <amantia@kde.org> Date: Fri Sep 16 11:15:51 2011 +0300 Make the maildir resource more standard compliant: - regarding file names (233379) - moving out files from new to cur (233378) - storing flags - reading flags from filenames (252449) BUG: 233380 BUG: 233378 BUG: 252449
At least "moving out files from new to cur" is not fixed in 4.7.2 for me. The naming changed but the mails stay in new/ directory.
(In reply to comment #5) > At least "moving out files from new to cur" is not fixed in 4.7.2 for me. The > naming changed but the mails stay in new/ directory. Ok, I have to correct this. When copying mails to a local maildir, they are stored in the new-folder, regardless of the message state (unread in this case). inbox/new/1318885447.R34.acer for example After marking them unread they where moved to the cur-folder correctly. inbox/cur/1318885447.R34.acer Marking them unread again resulted in correct naming in the correct folder. inbox/cur/1318885447.R34.acer:2,S Opening the message wasn't sufficient to move it to the correct place. As far as I understand maildir, this behavior still isn't fully standard-complient.