| Summary: | If default maildir folder is changed a new set of folders are stored under "/home/$user/file:" | ||
|---|---|---|---|
| Product: | [Applications] kmail2 | Reporter: | Nick <nick.craig.law> |
| Component: | folders | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | j.straight-kde, kde, Mathias.Homann, montel, rhautz, svckd, Vojtech.Zeisek, vomus |
| Priority: | NOR | ||
| Version: | 5.11.1 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kdepim-runtime/93ecfacfb9f21ee027dbcfc7d5d47ddbbb253ba1 | Version Fixed In: | |
| Attachments: | Dialog box where you change the maildir folder | ||
it's a problem with url vs string. I will investigate it soon That's great!. Thank You. For the moment I can't reproduce bug... I'll do a fresh install and see if I can find specifically what triggers this problem. One thing that is most likely different from the average install is that /home/nick/Data is a symbolic link to /media/nick/Data_sdb. /media/nick/Data_sdb is mounted at boot to /dev/sdb3 The df entry looks like this: /dev/sdb3 591G 556G 4.8G 100% /media/nick/Data_sdb (I know the partition is at 100%) And the /etc/fstab entry is: UUID=329dc068-a4ed-45fd-9b0b-0ef09ca926ee /media/nick/Data_sdb ext4 defaults 0 2 My initial thoughts are that this symbolic linking and use of a different partition 'may' have something to do with the problem. So my plan would be to start with a working install using the default maildir location, then change to a valid maildir folder on a different directory. Not forgetting the symbolic link. I'll update you if I can reproduce this on a fresh install. Just to note, I have tried deleting /home/nick/.local/share/akonadi and letting it rebuild but it still would not index the emails. On the same computer I created a new user. I then changed the default location of the maildir folder from /home/[user]/.local/share/local-mail to a folder called /home/[user]/emails. Both locations are on the same partition. No symbolic links are involved. kmail (or akonadi) then creates a directory file:/home/[user]/emails/inbox Even more oddly the ..inbox/ folder that contains the subdirectories new, cur and tmp, if you look inside new you will find another subdirectory called file: This path in full is shown here. This is created by either kmail or Akonadi. /home/marmite/file:/home/marmite/local-mail/inbox/new/file:/home/marmite/local-mail/inbox/new/new Ok I was able to reproduce it now. I have the same problem. In case jt helps, I noticed that when you use the dialog to change the Local Folder directory, the path in ~/.config/akonadi_mail_resource_0rc changes from Path[$e]=$HOME/.local/share/akonadi_maildir_resource_0 to Path[$e]=file:$HOME/local-mail I was able to get my mail back in the default Local Folders by following the steps to recover from a failed migration. The first time reset the location of Local Folders to the default without using the dialog box (so "file:" was not part of the path), and then I moved my mail files there, and went through the steps a second time, and kmail read all of my stored mail in. I no longer see the folder file: being created on my home folder but the issue of not being able to use a custom path to the maildir is still present. Createig any maildir type account always defaults to being created on ~/.local/share/akonadi_maildir_resource_xx. On Fedora 30, KDE Spin: kmail 19.04.2-2.fc30 akonadi 1.13.0-113.fc30 plasma-desktop 5.15.5-1.fc30 This just happened to me on Kubuntu 20.04 Thank goodness for the trash bin. I saw "file:" in my ~ and figured I probably did something stupid to create it with a bad redirection. So I trashed it. Few hours later, I realize 250MB of archived mail is gone. Ver: 19.04.3 I can confirm it on openSUSE Tumbleweed, KMail 5.13.2 (19.12.2), KDE Frameworks 5.66.0, Qt 5.14.1 (built against 5.14.1). Git commit 93ecfacfb9f21ee027dbcfc7d5d47ddbbb253ba1 by Igor Poboiko. Committed on 01/03/2020 at 18:44. Pushed by poboiko into branch 'master'. [resources/maildir] Don't save "file:" schema to the config Summary: `ConfigWidget` uses `KConfig` underneath, and utilizes `KUrlRequester` custom widget. The `USER` property of this widget (which is used by `KConfig`) is of type `QUrl`, and thus when dialog is accepted, the `path` config property gets overriden with `QUrl::toString()` value, which prepends `file:` schema (this is basically because `KCoreConfigSkeleton::ItemPath` is inherited from `ItemString`, and when someone calls `ItemString::setProperty`, it gets casted as `QVariant::toString`). Inside the `ConfigWidget::save` the code calls `setPath` method on `url.toLocalFile`, which drops the scheme. Because of that, the `pathItem` and `path` property of `mSettings` have different values, first has schema and the second hasn't. Eventually, the value stored by `pathItem` wins, and `mSettings->path()` returns URL with schema. However, `Maildir` doesn't expect it and misinterprets it as the relative path to current WORKDIR (which is home directory), thus creating `/home/user/file:/home/user/...` file structure. The proposed solution is to simply call `mSettings->save()`, which overrides `pathItem` value and drops schema from it. It also fixes the `AkoNotes` resource, which uses the same `ConfigWidget`. Funny enough, `Contacts` resource, which is somewhat similar, is not affected as it has the same `Settings->save()` call. Alternative approaches include: 1) Teach `Maildir` to drop the schema (if it's there). 2) Teach `KCoreConfigSkeleton::ItemPath` to work with `QUrl` and don't append schema (it makes sense, because `ItemPath` corresponds to local file. Although it's not documented that it shouldn't have schema, it seems from the tests that it was the original intent). This could save the headache of having such issue in the future, but it could mess up with other programs in funny ways (as currently `file:` sometimes gets prepended, and some code might implicitly rely on it) Additional note: There are `ui.kcfg_Path->url().isLocalFile()` checks around, which doesn't make sense to me, as `KUrlRequester` is used for local files and it seems like it always returns `QUrl` pointing to local file (i.e. have the `file:` schema). Related: bug 411269, bug 413588 Test Plan: 1) Open `akonadiconsole -> Local Folders` properties, change the folder, save 2) `cat ~/.config/akonadi_maildir_resource_0rc`. `file:` schema gets prepended 2.1) `akonadictl restart`. `file:` folder gets created inside homedir 3) Apply patch, repeat (1)-(2.1). `file:` schema is dropped. Reviewers: dvratil, mlaurent Reviewed By: dvratil Subscribers: kde-pim Tags: #kde_pim Differential Revision: https://phabricator.kde.org/D27722 M +1 -0 resources/maildir/configwidget.cpp https://commits.kde.org/kdepim-runtime/93ecfacfb9f21ee027dbcfc7d5d47ddbbb253ba1 *** Bug 411307 has been marked as a duplicate of this bug. *** *** Bug 424579 has been marked as a duplicate of this bug. *** |
Created attachment 120604 [details] Dialog box where you change the maildir folder If the default maildir folder is changed using the dialog box as shown in the attached snapshot then kmail fails to use that folder but creates a new folder under your home directory in a folder called "file:" Example: If you enter /home/nick/Data/local-mail as the folder containing your maildir files, kmail instead creates and uses /home/nick/file:/home/nick/Data/local-mail.directory/ which of course isn't where your maildir folders and files are ! Why is kmail creating a subdirectory called "file:" in your home directory ? The problem this creates is that any old emails that are in /home/nick/Data/local-mail don't get indexed or displayed by kmail. Also because kmail insists on creating a file: subdirectory in your home folder and storing new email there you can't have all your emails on a different partition to your home folder. KDE INFO KDE Neon 5.15 User Edition Plasma 5.15.5 Frameworks 5.58.0 QT 5.12.0 Kernel 4.15.0-50 OS 64 Bit