Bug 415922

Summary:	Changing/Setting maildir folder in settings is not working
Product:	[Frameworks and Libraries] Akonadi	Reporter:	Ralph Scharpf <rscharpf>
Component:	Maildir Resource	Assignee:	kdepim bugs <kdepim-bugs>
Status:	REPORTED ---
Severity:	normal	CC:	igor.poboiko
Priority:	NOR
Version:	5.11.3
Target Milestone:	---
Platform:	Kubuntu
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

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