https://bugs.kde.org/show_bug.cgi?id=325699
--- Comment #5 from Martin Steigerwald <[email protected]> --- Well, for current Akonadi setups I think the base of the relative path that makes the most sense is $HOME as everything is store there. But for configurability, i.e. in order to be able to separate Akonadi data from $HOME to place them somewhere else than NFS based home directories or whatever reason, it may make sense to reference some other environment variable. While I can deal with my current work-around not to use the CRM114 spam filter rules and well delete the spam that policyd-weight lets through manually, for further attempts to get to the cause of that severe data loss bug, I need a test enviroment that is 100% identical to my current production setup. Thats all I wanted to point out. I am not willing to test this on my real production setup once again, I am not willing to risk loss of mails in order to reproduce that bug once again, despite in a test setup. As a fresh from start setup didn´t trigger the issue, I need to copy the current setup as is. Only other way forward would running a virtual machine where I can have another /home/martin (instead of /home/martin2), but currently I do not have enough space on this SSD to do that. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Kdepim-bugs mailing list [email protected] https://mail.kde.org/mailman/listinfo/kdepim-bugs
