Marking it as critical, cause I see mail unread/read status as important data that the import process looses. On my second attempt to migrate from KDEPIM-1 to KDEPIM-2 I imported old mails via KMailCVT. I pointed KMailCVT at ~/Backup/Mail-Alt which is a copy of my old KMail ~/Mail folder. After having faced Bug 319157 - Excessive I/O usage during mail import with KMailCVT. and apparently worked around it with an akonadictl restart and after having it sort some, but not all stuff in file_db_data into the Maildir: martin@merkaba:/home2/martin> date ; du -sch Akonadi/* Nepomuk ; du -sch Akonadi/Datenbank/db_data Akonadi/Datenbank/file_db_data Mi 1. Mai 13:10:57 CEST 2013 6,3G Akonadi/Datenbank 72K Akonadi/Konfiguration 2,6G Akonadi/Mails 543M Nepomuk 9,3G insgesamt 2,5G Akonadi/Datenbank/db_data 3,9G Akonadi/Datenbank/file_db_data 6,3G insgesamt and after Akonadi appears to be idle while there are still 3.9 GB of mails in file_db_data, I still see more than 7500 mails in my inbox. Including lots of mails I have definately read. Same goes with other folders. Reproducible: Always Steps to Reproduce: 1. Fresh KMail2/Akonadi setup 2. Import old KMail1 ~/Mail 3. Wait for it to complete or for Akonadi to be idle in process list. Actual Results: Mails unread/read status does not reflect last state in KMail 1, although index files have been available in the original imported ~/Mail. Expected Results: Mails unread/read status is imported, just like then pointing a mixed maildir resource to the directory. The directory does not contain any mbox files. I think I will try just this, as a *third* attempt. I will point a mixedmail dir resource at my old mails. And use the existing local folders resource for new mails. I might try to move some folders over, but maybe I just will retrieve new mails in Local Folders and keep the old one in the mixed mail dir resource. Sorry, but migrating from KMail-1 to KMail-2 is nowhere near end-user ready. Not at all. Thats at least my experience. I hope the third attempt will work.
Created attachment 92991 [details] Screenshot error message - failure to import messages.
I can confirm the misbehaviour of kmail2/kmailcvt. After losing all my network/internet access settings I was forced to reinstall my complete system. I backed up my /home folder to external harddrive first to have backup also of my old emails. I then reinstalled linux on my system, then reinstalled kmail2 (version: 4:4.14.2-2 I then wanted to import my old emails from external backup folder. So I opened "Datei" -> "Nachrichten importieren..." ("File" - "Import messages..."), added an extra folder for import messages and then browsed kmail2 to my backup folder. It started importing all sorts of stuff, including images, icons, even MYD files, XML-files and binaries, but also started to import real old mails. It stuck with attached error message: "Fehler: Nachricht kann dem Ordner new nicht hinzugefügt werden. Ursache: Unknown collection for '610'". ("Error: Messsage cannot be added to folder new. Reason: Unknown collection for '610'"). Note the double language error message (half way German, half way English). Note the useless information "610". The first time this message appeared it was attempting to access news in folder /local/share/local-mail/Job/XING/new. "Job" and "XING" are folders I created in kmail2 for collecting messages sent to/by XING Apparently kmail2 /kmailcvt was unable to import messages from NEW folders. I could restore a number of backupped messages, but I still miss a lot of very important old messages that contain important information for me and/or are valuable for me for private reasons. What can I do to recover these mails? Could it be a permission rights problem?
Created attachment 96032 [details] Collections with existing "new" subcollection Same here, some messages from "new" maildir folders are not imported, kmailcvt shows the error message noted above. Indeed in AkonadiConsole I can see that the expected collection is missing. E.g. folder "foo" exists with ID 1500, but kmailcvt seems to expect a collection with ID 1501 instead. For some collections, a subcollection named "new" seems to exist though (see attached screenshot of the DB browser). I have no idea as to why this does not work for all folders.
I forgot to mention: This happens for 4.14.8 here.
One more thing: the popup message comes up for every single message going to said missing folder/collection. For use cases like restoring mails from an older installation this can mean minutes of keeping the Return key pressed.
Workaround: Since only "new" folders are affected, and the problem does not appear for every folder, manually importing just the affected folders works (most of the time) helped me around this bug. When choosing to import from the "undotted" directory (with tmp, cur and new subfolders), I can simply transfer all mails from the "new" subfolder into the original folder later. That this bug only appears every now and then makes me believe it's probably a race condition with the folder/collection creation. My machine was under pretty heavy load when importing, also because akonadi_baloo_indexer was running simultaneously at high load.
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years and I will be closing this bug.