Version: 1.99.0 (using KDE 4.7.2) OS: Linux apparently it is no more possible to control data location whatever th tools uses to handle data (nepomuk, akonadi, mySQL) Reproducible: Always Steps to Reproduce: try lo locate data Actual Results: for the time being no way for example to share the same mail data through nfs on a local network ; besides I do not like the idea to put all critical data under "/home/the_user" and I prefer to install it ander a specialized partition through a link ; this is no more possible Expected Results: change the location of data OS: Linux (x86_64) release 3.0.0-12-generic Compiler: gcc
I fully support this. I am on pop3 and always had my mail stored in a separate partition called "Mail". Makes it very easy to backup and restore (or move to a new machine) With the new Kmail2, the email sits somewhere in a .local/share/akonadi/file_db_data/ directory without any copies made in the ~Mail directory. I really fail to see the logic behind hiding the mail in a "cache like" directory without proper means to back it up. On IMAP this might not be a too big issue, on POP3 it is suicide.
Daniel, Frits, thank you for your report and your comment. Sorry for taking long time to answer. The location of the Akonadi cache files is not configurable, thats right. But the location where the mails are stored – usually ~/.local/share/local-mail – permanently is. You can set this path in the maildir resource config. That said, while Akonadi in general is only a cache, there can be an interim time where some mails are only in file_db_data or the database. Also there are links from local filter configuration that are dependent on the database. The development team is aware of both of it and there are ideas to at least let the resource provide an unique ID that is independent of the database, yet it is not sure how to implement this for some of the resources. Also you can have database and mail data on NFS. I had it for years. Depending on backend storage for NFS there can be an issue with the amount of files in file_db_data directory. For that I suggest to use Akonadi 1.13 with patch that avoids leaking files in there. Akonadi 15.12 will also contain a leveled file cache so files are spread into sub directories. Also you can set symlinks to relocate mail directory and database to some other partition. I did this during the time where the amount of files in file_db_data where to much for our backend storage. I relocated the ~/.local/share/akonadi from NFS to Ext4 that way and I am still using that setup. But I will likely switch it back to NFS soon. So at least you can relocate data using symlinks. Thats for some background for you. I can´t promise whether your wish will be implement, but that Akonadi currently at times is more than the cache it was meant to be, is known to the development team.
*** Bug 285242 has been marked as a duplicate of this bug. ***
Hi Martin, Thank you very much for the very informative and lengthy answer. This is much appreciated! I had -almost- forgotten about it already again, but your email gives me some good ideas. I actually have a good NFS storage at home (with regular backups) and it really is worth looking into either storing it there or alternatively do it on a separate /Mail partition using some of the techniques you outline. So once again, thank you VERY much! At least it is a workable solution, although having an option in the " configure Kmail" where to store email would still be nice. A nice to have. Not a must to have. And I must say that KMail (and Kontakt) as a whole is actually behaving quite good lately. Still have the odd "duplicate messages" in folders sometimes, but have not been able to pinpoint what is causing it. I am really looking forward to the Plasma 5 version of Kontakt! Kind regards and my compliments to the development team! Frits