Bug 416287 - It's not possible to add an existing maildir, the wrong path is used
Summary: It's not possible to add an existing maildir, the wrong path is used
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: Maildir Resource (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR major
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-15 12:01 UTC by Tobias Leupold
Modified: 2020-05-03 12:18 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Directory listing of KMail's newly added "local mail" folder (8.20 KB, text/plain)
2020-04-07 11:31 UTC, Tobias Leupold
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Leupold 2020-01-15 12:01:37 UTC
I recently switched to a new machine and thus tried to create a new "clean" home directory and also KMail profile. I copied over all my existing local maildirs (that have been created usign KMail, same version, same state of Gentoo), but it wasn't possible to add them.

Adding a maildir resource pointing to the existing data just adds an empty entry "akonadi_maildir_resource_1". The data of the actual maildir is not shown. The directory ~/.local/share/akonadi_maildir_resource_1 is created. If I create some subfolder via KMail, it's added to that path. Still, editing the resource shows the actual path (~/.local/share/archive-mail in my case). Setting it again to the (already displayed) correct path doesn't help.

Copying my whole home directory including all config files (whatever the whole akonadi/kmail thing may need, I also didn't manage to find out which very files those are) restored the original state.

This can easily produced using a new user with an empty home directory. Happens every time. Just try to add an existing (Akonadi/KMail-created) maildir to a new profile.

I have kde-apps/akonadi-19.08.3 and kde-apps/kmail-19.08.3 installed.

This is really major breakage! I would glady help to debug this.
Comment 1 Rigo Wenning 2020-02-05 07:24:37 UTC
I can confirm this after update of opensuse tumbleweed and update of postgres to version 12. While my IMAP accounts work, kmail2 has lost the local-mail. Pointing it to local-mail creates a new resource. But this new resource does not retrieve the emails available in .local/share/local-mail Actually, deletion of local-mail is greyed out. I guess something went wrong with the database
Comment 2 Rigo Wenning 2020-02-05 07:30:01 UTC
BTW, I moved local-mail to mail.backup and tried to add that one as maildir or Kmail folders. System says "no usable storage location configured".
Comment 3 Tobias Leupold 2020-04-07 11:31:05 UTC
Apparently, there's more breakage. I messed with the "Local mail" folder on my father's machine. After moving some folders around, deleting some and renaming some, the whole local mail folder was gone at some point (without restarting akonadi or kmail!), including all mails.

Happily, the actual mails stored in ~/.local/share/local-mail were not deleted, but only a new local mail folder was added. This time not ~/.local/share/akonadi_maildir_resource_xxx, but a much more interesting path: ~/.local/share/file:/home/gerhard/.local/share/local-mail and ~/.local/share/file:/home/gerhard/.local/share/.local-mail.directory (yes, really).

Something in Akonadi/KMail is really, really broken at the moment.

I'll add an attachment showing what directory structure KMail created inside this highly suspicious folder. I couldn't reproduce this with a new user though.

Also, I wasn't able to clean out KMail's config to start again with a clean one. I moved all folders and files in ~/.local and ~/.config who's names are "kmail*", "email*" and "akonadi*" to kmailrc~ and so on, but kmail seems to be really unimpressed by this: Starting akonadi and kmail again, I still saw the same folders and accounts (how can this even happen?! Where the hell is this stored?!)

I don't want to be bitchy. But this is REALLY MAJOR BREAKAGE. Please, do anything about this. Tell me what I can do. I can code a bit C++ and Qt, but KMail and Akonadi is too big for me. Maybe, I can help if you tell me where to start.

But put your hand on your heart! You can't be serious about one of KDE's flagships being that broken at the moment and there isn't one single developer seeing the same and commenting here.

Please rescue KMail!
Comment 4 Tobias Leupold 2020-04-07 11:31:43 UTC
Created attachment 127345 [details]
Directory listing of KMail's newly added "local mail" folder
Comment 5 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 415245, bug 415922

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