Bug 352502 - .local/share/local-mail has to be the top level of local folders!
Summary: .local/share/local-mail has to be the top level of local folders!
Status: REPORTED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: Maildir Resource (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-09 22:37 UTC by piedro
Modified: 2020-04-27 10:41 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description piedro 2015-09-09 22:37:17 UTC
The local folder for kmail2 uses the maildir default which also creates a hidden folder .local-mail.directory containing the subfolders with the actual email files... 

That's what kmail2 decided to go with and I accept that as it is their decision. But it is a huge omission not to set .local/share/local-mail as the top level mail folder! 

The problem is simple: 
A user wants to set his local folder ressource to /home/mail (for example because he uses different logins and wants to grab the same mails with each login. Now akonadi will have problems because the user has no permission to write into the /home directory. So the hidden directory for the maildir structure cannot be created. But this is only an extreme example of all the problems that have been invited with the decision to let akonadi create a hidden maildir BESIDES the "local-mail" folder instead of WITHIN which should be the default for many reasons. 

First let me state that there is no problem with the initial default setup as such - it will work at first. 
But once things go wrong or a user customizes the location of the "local folders" inkmail things get ugly.... 

1. a user setting "local folders" to say ~/Documents/MyLocalMail will run into problems when trying to backup his documents. For one he wouldn't expect any hidden fodlers in the document root nor would he backup the hidden folder when he is creating a backup on a thumbdrive for example... 

2. as mentioned before a user needs only the permissions to work in the folder he chooses for "local-mail" but akonadi expects the same permissions for the containing folder. That is a huge problem in many use cases. For example the user wants to secure his mail local mail folder by restricting permissions to 600 for the "local-mail" folder as set in the akonadi ressource - the mails in all subfolders are not set to 600 because they are not contained within the "local-mail" folder. 

Please note that it is not a solution to assume that a savy user will know, read the bare documentation and remeber to search for the hidden files to also change the permissions.... 

3. as it is well known akonadi crashed a lot up till now, things changed and had to be reset from time to time for many users. Everytime the "local folders" are automatically recreated they default to ~/.local/share/local-mail. Now resetting the resource to the old location invites trouble because the hidden *.directory folder might not be at the expected location anymore or the old location has changed loosing the connection to the hidden folder. Happened to me many times. 

4. symlinking "local-mail" to another partition to have a safe mail storage location on a more secure (maybe encrypted) location for your local mail falls into the same traps and is prone to loose all mails in subfodlers cause they are not in the location the symlink links to.  

Now there has always been a solution to add a line into the resource configuration file to use the "local folder" resource folder as the top level folder. 

It's not really documented anywhere but it's something like "directory IsTopLevelFolder". 
This results in all mail being stored WITHIN the "local-mail" folder and only here hidden *.directory subfolders are created. This solves all the above problems. 

Sadly after a crash local folders get recreated (and lets be honest they get recreated a lot!) ignoring the old resource settings. So they start creating unwanted hidden folders in ~/.local/share again and again and again... 

Since I lost all my Kjots notes (a similar problem!) I do not remember the exact syntax to force the directory to be the "TopLevelFolder" (I'd be happy if someone would remind me here...) but I do not understand at all why this behaviour is not the default for akonadi's local-mail folder resource.  

The default resources and contacts are ~/.local/share/notes and ~/.local/share/contacts in every case all the files are contained WITHIN these folders please be consistent and place all the maildir folder shenanigans inside the local-mail folder by default. 

Btw, I am pretty sure that many of the open bugs for local folders and/or lost or invisible mails, disappearing folders in kmail and so forth are related to this and can be drastically reduced by setting the default to keep the maildir structure INSIDE the chosen folder for local mail. 

I am sure there are initial reasons why this was organized the way it is at the moment but this is a big inconsistency. If you ask a user where to put his/her local mail via an akonadi resource setting dialog than he user has to expect all mail (in whatever structure it might be) is in deed contained in the folder he or she chose.    

this has to be a really easy fix if this "IsTopLevelFOlder" setting is still working and can be added to the default. 

thx for reading this rather long one, 
cheers, piedro

Reproducible: Always
Comment 1 piedro 2015-09-09 22:39:23 UTC
sry for typos, I can see no way to edit afterwards?
Comment 2 piedro 2015-10-14 09:18:31 UTC
This is connected with this bug here: https://bugs.kde.org/show_bug.cgi?id=339680
Comment 3 piedro 2016-03-29 10:46:25 UTC
Why do I go through the trouble of reporting a clear mis-design in length and make suggestions. 

There is always this call for participation, bug reporting and contributing to the project... 

I start think this is wishful thinking. Nobody seems to even acknowledge any entry - neither with a comment nor with any actual changes so why bother....
Comment 4 piedro 2019-02-26 16:37:40 UTC
Now this is still present and unsolved in KDE 18.12.1! 

Creating the hidden directory list OUTSIDE the designated local mail folder is a serious bug. 

In connection with the bug of akonadi creating folders BEFORE the user confirms or intentionally chooses the Mail folder location recreates empty directory list folders over and over again and messes up the local folder in kmail. 

Because of this subfolders change their name, are recreated, disappear and get moved within the system. It's the source of a whole bunch of problems people complain about. 

Well as nobody seems to read these bug reports this will stay like this I guess. 

And that's exactly one reason why kmail is unusable for many people cause you can't even use an archive subfodler in local folders... 

Keep up the good work! 

p.
Comment 5 Igor Poboiko 2020-04-27 10:38:27 UTC
Git commit 4447e8894d4f3b4c08849956f33aa7156caa30a4 by Igor Poboiko.
Committed on 27/04/2020 at 10:38.
Pushed by poboiko into branch 'master'.

Save configuration when creating resources for new user

Summary:
Akonadi calls `writeConfig` DBus method to save the configuration for newly
created resources, both via `firstrun` and `SpecialCollections` mechanisms.
This method is non-existent for all of the resources (it was deprecated in
KConfig, and apparently is not exported to DBus), method `save` should
be used instead.

This is related to issues raised in {D27905}: settings provided in firstrun did
not override default settings for the resource.
Related: bug 345211

Test Plan:
1) Check `qdbus org.freedesktop.Akonadi.Resource.akonadi_maildir_resource_0 /Settings`
2) There is no `writeConfig` method, but there is `save` method

Reviewers: dvratil

Reviewed By: dvratil

Subscribers: kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D28523

M  +1    -1    src/core/firstrun.cpp
M  +1    -1    src/core/jobs/specialcollectionshelperjobs.cpp

https://commits.kde.org/akonadi/4447e8894d4f3b4c08849956f33aa7156caa30a4
Comment 6 Igor Poboiko 2020-04-27 10:41:48 UTC
Git commit 1a13474c9a53e8b4b485a27189ff26f309f7fccb by Igor Poboiko.
Committed on 27/04/2020 at 10:41.
Pushed by poboiko into branch 'release/20.04'.

Save configuration when creating resources for new user

Summary:
Akonadi calls `writeConfig` DBus method to save the configuration for newly
created resources, both via `firstrun` and `SpecialCollections` mechanisms.
This method is non-existent for all of the resources (it was deprecated in
KConfig, and apparently is not exported to DBus), method `save` should
be used instead.

This is related to issues raised in {D27905}: settings provided in firstrun did
not override default settings for the resource.
Related: bug 345211

Test Plan:
1) Check `qdbus org.freedesktop.Akonadi.Resource.akonadi_maildir_resource_0 /Settings`
2) There is no `writeConfig` method, but there is `save` method

Reviewers: dvratil

Reviewed By: dvratil

Subscribers: kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D28523

(cherry picked from commit 4447e8894d4f3b4c08849956f33aa7156caa30a4)

M  +1    -1    src/core/firstrun.cpp
M  +1    -1    src/core/jobs/specialcollectionshelperjobs.cpp

https://commits.kde.org/akonadi/1a13474c9a53e8b4b485a27189ff26f309f7fccb