Version: Git (master) (using Devel) OS: Linux When you move (by dragging) an IMAP folder to another parent, it immediately shows as moved. However, sometimes, on the server it's not moved at all. It simply disappears. This is data loss. I lost over 54k emails today because of this. Reproducible: Sometimes Steps to Reproduce: 1) choose a folder 2) drag it to another parent Actual Results: The folder disappeared, the contents along with it. Expected Results: Folder is moved on the server and stays there. OS: Linux (x86_64) release 3.1.6-1.fc16.x86_64 Compiler: gcc When I tried to reproduce the problem, I couldn't. The test folder with 2 was moved properly. It might be that the IMAP agent was busy in the background doing some non-visible tasks when I moved. I did restart Akonadi a few times this afternoon. The folder's disappearance happened after I restarted it -- I am sure I could see it before one of the restarts, though I cannot verify that the data was still on the server. I restarted Akonadi because it would not update the folder list. Please, please, PLEASE make *ALL* and every single activity show up in the UI. NO activity, no matter how small, should be in the background. Bring them all to the foreground with UI visibility so I know when it's ok to shut down.
Part of this is related to bug 288140.
This looks like it could be the bug I just encountered. What I did was: - Rename IMAP folder 'Archives/2010' to 'Archives/Gentoo-User-2010', using Claws Mail - Wait until KMail shows this folder with its new name. Got some Akonadi errors meanwhile, but I'm getting used to it - Move this folder to 'Local Folders/Backup/', a local maildir resource. After a while, I got LOTS!! of notifications: - Local Folders: Error: Not supported type (this one for dozends of times). - Virtyou: Connection aborted - Virtyou: There is no connection to the IMAP server - Local Folders: Item query returned empty result Kmail crashed then. After restart, the Archives/Gentoo-User-2010 folder is gone. But 'Local Folders/Backup' is still empty. So, it seems that KMail just ate a whole folder containing 12,000 mails. I confirmed by looking into .local/share/.local-mail.directory/.Backup.directory/, there is nothing besides the cur, new and tmp directories. When I drag single mails into this folder, they do show up both in KMail and in the directory. This is reproducable, I tried this three more times, also using a different IMAP server: - create a sub-folder on the IMAP server (it seems KMail does not allow to create top-level folders) - copy some mails into it - move this folder anywhere to the local mail directory - the folder appears, and also the mails in it - but they disappear after a second - I cannot find those mails in the file system, it seems they are simply gone This is SCARY! And I assume this does not happen for everyone, and there is something strange in our setups. But I wonder why there are no comments yet, not even someone saying the same does not happen for him, or asking for more details in order to reproduce. This is about data being lost! In my case it's not important, just an archived mailing list, and I even have a backup, but this can be really bad for other people. I'm using KDE 4.8.1 on Gentoo Linux.
*** Bug 291006 has been marked as a duplicate of this bug. ***
Setting status to critical as it leads to data loss. Marking as a release blocker
Confirmed to be present in Kmail2 4.11.2 on OpenSUSE KR11 repositories. I copied a folder from my imap account into a local account. Now an entire tree of local folders has disappeared. Verifying via shell, all the emails are there. Folders also disappeared in akonadiconsole, so maybe also a bug of akonadi
(In reply to comment #5) I finally found what went wrong: When moving messages from imap to local folders by dragging over the folder, kmail2 changed the configuration of local folders from .local/share/local-mail to .local/share/akonadi_maildir_resource_0/ and put a new set of empty maildirs in there. Manually setting the Local Folders agent in Akonadiconsole back to .local/share/local-mail made the entire thing re-appear.
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.
Denis, Opensuse Leap still uses Kontact 4.14.10 and only Leap 42.2 will bring KF5 for KDEPIM. Closing those bugs without the reporters having a chance to test is IMHO premature. In the meantime, I tested KF5 and reverted as there were other issues that I can't remember (I also used Postgres which worked much better). So I decided to wait for the official move from the OpenSuse KDE team to move to the new platform. In the meantime, I use mutt to move emails to avoid data loss.
(In reply to Rigo Wenning from comment #8) > Denis, > Opensuse Leap still uses Kontact 4.14.10 and only Leap 42.2 will bring KF5 > for KDEPIM. That's not true. Leap 42.1 has KDEPIM 15.12.3 (i.e. 5.1.3) too. It just won't be replaced automatically. Leap 42.2 will come with the latest 16.08 (i.e. 5.3), and 4.14.10 for "compatibility".
True/Not true :) It won't install without explicit act, because this changes vendor to obs://build.opensuse.org/KDE instead of the main repositories. I had that already and it went wrong. So I wait until they have tested this out and include in the main repos. And In November 42.2 will come with the new KDEPIM in the main repositories and I will be able to try. My only point is that closing those bugs is premature. I know that there was a lot of coding with regard to I/O and email transfer in the meantime. But it hasn't been tested yet by those who raised the issue
(In reply to Rigo Wenning from comment #10) > True/Not true :) It won't install without explicit act, because this changes > vendor to obs://build.opensuse.org/KDE instead of the main repositories. No, it doesn't. KDEPIM 15.12.3 is part of the main repos. But it is true that it won't be installed automatically (as I wrote), and that won't change in Leap 42.2 either. We still let the user decide whether they want to switch to the latest KF5 version or rather stay on 4.14.10, for certain reasons.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.