Bug 415922 - Changing/Setting maildir folder in settings is not working
Summary: Changing/Setting maildir folder in settings is not working
Status: REPORTED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: Maildir Resource (show other bugs)
Version: 5.11.3
Platform: Kubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-06 10:51 UTC by Ralph Scharpf
Modified: 2020-05-03 12:18 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 Ralph Scharpf 2020-01-06 10:51:22 UTC
When a new maildir resource is created referring to an already populated maildir (what most people will want to do), the existing content will not show up. 

When an existing maildir (e.g. the one that is created per default) is set to a maildir at an other place, also the content will not show up.

In both the ways, adding entries (via kmail) to the created/changed maildir resource will add the entries at the default location of the maildir, e.g. somewhere at ~/.local/share/

Another observation that came along with this, not clearly knowing if this is a bug or a feature: When the given path is outside the home directory tree, the selected directory will be replaced by an URL starting with file:// (in my case file:///data/user/mail/ when selecting the path /data/user/mail). I did not see this behavior in previous versions of akonadi used.

STEPS TO REPRODUCE

1. Copy some mail into a directory
2. Create a maildir resource using kmail/kontact 

OBSERVED RESULT

The resource will not show any mail content in kmail/kontact. Adding mail to the resource will store it in a maildir at .local/share/


EXPECTED RESULT

The maildir resource should really switch to a given location, not just show it in the dialog  


SOFTWARE/OS VERSIONS

Linux/KDE Plasma: Kubuntu 19.10
KDE Plasma Version: 5.16.5
KDE Frameworks Version: 5.62.0
Qt Version: 5.12.4

ADDITIONAL INFORMATION

Workaround: By changing the setting Path of the resource through akonadiconsole (resource context menu -> Configure -> Configure Remotely), the maildir resource can be forced to read it's mails from the expected location.

The same error is reported already in Bug 415245, but I fear this will be hard to catch. I hope my description is a bit more helpful.
Comment 1 Igor Poboiko 2020-03-05 16:08:34 UTC
This is probably related to bug 408354 - the path was misinterpreted as ~/file:/data/user/mail, which is obviously not the right place to look at.
Do such folder get created in your case?
Comment 2 Ralph Scharpf 2020-03-05 19:09:22 UTC
Hi Igor,

I gave it a try. I created a new maildir resource at /tmp/dummy.

In the native configuration I get displayed the path: file:///tmp/dummy 

In the "remote" configuration dialog the Setting "Path" is set to "/home/ralph/.local/share/akonadi_maildir_resource_5" 

The directory /tmp/dummy was created as empty directory with also no hidden files in it. The directory inside .local was not created. 

When I try to drop a mail into the newly create resource nothing happens.

Now I created another maildir resource to store mails at ~/.local/share/dummy. Again, the directory was created at the given place. In the native dialog the resource shows the path as "/home/ralph/.local/share/dummy/". IN the remote configuration the path is set to /home/ralph/.local/share/akonadi_maildir_resource_6 which is again not available.

No I created the directory ~/.local/share/akonadi_maildir_resource_6 manually. Again, trying to drop an email into it does not work. I also tried to add cur, new and tmp dirs and to restart akonadi via akonadictl. The resource does not work!

Thje said, the observation is slightly different as I never saw valid mails in .local/share, most likely as this path was never created.

Does this help?
Comment 3 Igor Poboiko 2020-05-03 12:18:38 UTC
Git commit 4ab1f2068b53d3fabe3cf35c087f28bf10bca672 by Igor Poboiko.
Committed on 03/05/2020 at 12:18.
Pushed by poboiko into branch 'release/20.04'.

[resources/maildir] Reload configuraton on configuration change

Summary:
When user adds new maildir, a new resource gets created, with the default
directory `~/.local/share/local-mail`. Since it's a new resource, with no
proper configuration, an `attemptConfigRestoring()` is called, which changes
it to `~/.local/share/akonadi_maildir_resource#`. It's stored inside
`mSettings->path()`.

Then a dialog appears, where user can choose prefered directory. It gets
written to the config file; then `configurationChanged` gets called.
We call `mSettings->save()`, which overwrites the path provided by user with
the default one (`~/.local/share/akonadi_maildir_resource#`), making it
impossible to create a new maildir anywhere else.

Just use `load()` instead, it makes more sense when configuration was changed.
Related: bug 416287, bug 415245

Test Plan:
1) Create a new maildir resource pointing to `/tmp/dummy`.
2) The resource gets created, with the name `dummy`. `/tmp/dummy` gets created.
2) Drop some mails into it via KMail. Mails appear inside `/tmp/dummy`

Reviewers: dvratil, mlaurent

Reviewed By: dvratil

Subscribers: wbauer, kde-pim

Tags: #kde_pim

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

M  +2    -1    resources/maildir/maildirresource.cpp

https://commits.kde.org/kdepim-runtime/4ab1f2068b53d3fabe3cf35c087f28bf10bca672