Kmail trash map lost it's trash functionality

A user empties her trash map once a week by right click on the map and choosing Empty Trash.

Today the “Empty Trash” item was changed to “Move all message to Trash” which is the same as on all maps except the Trash map. She clicked on it out of habit and the trash map is empty now. The text “Move all …” is greyed out because the map is empty, but it is still the wrong text.

Moving a mail to trash removes the mail from it’s own map, but it does not show up in the trash map. No idea where it went.

So it seems that the Trash map somehow lost it’s special function as being the trash map.
Hovering over the map does show a trash-bin image anyhow.

Trying to find what makes a map the Trash map, I failed. It is not inn the folder properties of the map. Nor can I find it in the Kmail Settings.

Anybody an idea where to look?

Hi Henk,

is it possible that the said trash map is on an IMAP server? Because I have the same phenomena here (for longer time already, not recently). The IMAP trash bin is just a folder just as any other. Right mouse click I can only “move to trash”. I always gathered kmail can’t identify the trash as trash bin on an IMAP server but I never actually bothered.

But I still have a local mailbox to which I download from POP3 and that trash shows as a proper trash bin which I can empty.

I use POP3. no IMAP.

And, like with your POP3 it worked for years. And it also still works on another system with the same up-to-date 15.2.

Hmm, would have been too easy, wouldn’t it? Unfortunately, I can’t find any difference in the properties of my both trashes that would explain that behaviour. I changed the icon for the IMAP trash but that didn’t do any other change.

Found a few things. It is getting weirder and weirder, but hey, this is about KDE :(.

I tried to find the map structure on the system without the problem. Maybe I could learn something from it and compaiire.

I found it in ~/.local/share/local-mail. One item there is the directory ~/.local/share/local-mail/trash which indeed in its directory ~/.local/share/local-mail/cur has the same number of files as my trash folder shows. So far so good.
What I could not find is any hint on why this directory with the name trash is connected to being the trash folder (ony by name??)

Going to the system and user with the problem. ~/.local/share/local-mail does not exist?!?
Tried using find . -name ‘rash’ from .local and found that the structure I found on the other system is here in ~/.local/share/akonadi_maildir_resource_0/ .

Do not really know how to interpret this, but the use of find had one advantge, I saw more then one trash mentioned. It was in the .draft.directory directory. And indeed, looking now at the Kmail window I saw that Drafts had a > to show that it has sub-folder(s). And there it was, the original Trash with it. contents.

We do not know how it happened, but apparently:

  • the real Trash was moved as sub-folder of Drafts;
  • a new folder Trash was created, that is not the real Trash, but only has the same name*).

What we did so far:

  • removed the fake Trash;
  • tried to move the real Trash to it’s proper place, but failed, we can’t see how to do that.

Thus when anybody knows how to move that Trash, I will be grateful to get your advice.

*) The names of the directories is in all cases trash, but the name shown in Kmail is Prullebak (the Dutch translation, please do not try to pronounce that if you do not know how).

Most administrators want the users’ mailboxes to use a consistent path. I configure postfix on all machines:

**erlangen:~ #** postconf home_mailbox 
home_mailbox = .local/share/local-mail/inbox/ 
**erlangen:~ #** 

Mailbox is disabled by the above configuration:

**erlangen:~ #** ll /var/spool/mail/ 
total 0 
**erlangen:~ #**

Sending a mail to user tester creates the bold folders:

**erlangen:~ #** find /home/tester/.local/share/local-mail/              
/home/tester/.local/share/local-mail/ 
/home/tester/.local/share/local-mail/tmp 
/home/tester/.local/share/local-mail/drafts 
/home/tester/.local/share/local-mail/drafts/tmp 
/home/tester/.local/share/local-mail/drafts/new 
/home/tester/.local/share/local-mail/drafts/cur 
/home/tester/.local/share/local-mail/new 
/home/tester/.local/share/local-mail/cur 
/home/tester/.local/share/local-mail/templates 
/home/tester/.local/share/local-mail/templates/tmp 
/home/tester/.local/share/local-mail/templates/new 
/home/tester/.local/share/local-mail/templates/cur 
**/home/tester/.local/share/local-mail/inbox 
/home/tester/.local/share/local-mail/inbox/tmp 
/home/tester/.local/share/local-mail/inbox/new 
/home/tester/.local/share/local-mail/inbox/cur 
**/home/tester/.local/share/local-mail/inbox/cur/1621077247.V10304I13a0890M496129.erlangen:2,S 
/home/tester/.local/share/local-mail/sent-mail 
/home/tester/.local/share/local-mail/sent-mail/tmp 
/home/tester/.local/share/local-mail/sent-mail/new 
/home/tester/.local/share/local-mail/sent-mail/new/1621077766805.R435.erlangen 
/home/tester/.local/share/local-mail/sent-mail/cur 
/home/tester/.local/share/local-mail/outbox 
/home/tester/.local/share/local-mail/outbox/tmp 
/home/tester/.local/share/local-mail/outbox/new 
/home/tester/.local/share/local-mail/outbox/cur 
/home/tester/.local/share/local-mail/trash 
/home/tester/.local/share/local-mail/trash/tmp 
/home/tester/.local/share/local-mail/trash/new 
/home/tester/.local/share/local-mail/trash/cur 
**erlangen:~ #**

Upon initial invocation of kmail the inbox is detected and folders are added as listed above.

Do not really know how to interpret this, but the use of find had one advantge, I saw more then one trash mentioned. It was in the .draft.directory directory. And indeed, looking now at the Kmail window I saw that Drafts had a > to show that it has sub-folder(s). And there it was, the original Trash with it. contents.

We do not know how it happened, but apparently:

  • the real Trash was moved as sub-folder of Drafts;
  • a new folder Trash was created, that is not the real Trash, but only has the same name*).

What we did so far:

  • removed the fake Trash;
  • tried to move the real Trash to it’s proper place, but failed, we can’t see how to do that.

Thus when anybody knows how to move that Trash, I will be grateful to get your advice.

There is no fake trash. All these folders are real. For a smooth move of inexperienced users log them out and perform the move as root. See also Maildir - Wikipedia

*) The names of the directories is in all cases trash, but the name shown in Kmail is Prullebak (the Dutch translation, please do not try to pronounce that if you do not know how).

I don’t know how to change the displayed name using kmail. I use akonadiconsole instead.

akonadiconsole > Browser > Papierkorb > Properties > Attributes shows:

ENTITYDISPLAY ("Papierkorb" "user-trash" "" ())
SpecialCollectionAttribute trash

Change if needed.

I am not sure if the above is an explanation of my amazement that this directory structure is to be found on two different places in two systems which have a rather same history of installation and upgrades. It’s is not very important as I have found them and they seem to function wherever they are. It only made comparing the two a bit more complicated.

You misunderstood my use of the word “fake” here. I just used it as a shortcut to what I described more extensive as the directory with the name trash (show as the Prullebak folder in Kmail) that is on the place where we expect the Trash (also noted as Prullebak) folder. But it isn’t the Trash folder. Mails moved to trash are not going there and the menu item “Empty Trash” isn’t available (but the item “Move all to trash” is, as on every other “normal” mail folder).

So it is where Trash should be, it is names Trash, but it has the same properties as every “normal” mail folder. That is why I called it “fake” to differ it from the folder with the same name found as a sub-folder of Drafts that does have all the properties of Trash.

Of course all the directories associated with this folder structure is very real and not fake.

I do not really want to change the name of the folder. Apparently it is translated to the local language. I find it strange however that directories like drafts and trash are translated to their Dutch equivalents as folder names, apparently regardless if they are real trash or only have the name trash. Other folders, created by the user, have the same name as folder as well as directory. Somewhere there must be a list of folders that are seen as integrated to Kmail.
But again it is curiosity more then problematic (except that in this case it did not make things easier to understand.

What I still want is ti repair the place where Thrash/Prullebak is now. I want it back on it’s normal place.
To check what the “normal place” was (after all I only had the word of the user), I looked into the backups. Last backup (a week ago on Tuesday, thus one day after the user succeeded in emptying trash in her normal way), there was still only one trash on it’s normal place and it contained some removed mails. In other words, a week ago all was as expected.

Now you say you, like me, can not find a way to move that folder (or any folder) by mouse actions in the Kmail GUI.

I first thought that the user had moved thrash by some “wild” mouse/keyboard action. But as nobody knows how to do that, I doubt we can blame the user. I am still wondering how the move (and creation of the “fake” trash) took place.

The “fake” trash is now removed in the normal way (from the Kmail GUI).
I can of course move the trash directory from within .draft.directory to its normal place in the directory structure. I assume that it will then show in it’s normal place after restarting Kmail. But I am unsure if the capacity as Thrash folder will travel with the directory. In other words, I am afraid that by moving the directory, I will only create a new “fake” trash and have no Trash anymore.

You talk about akonadiconsole. Is that really something and end-user should know about? (I never used it).

Henk,
Haven’t found this in the KDE Documentation but, on the problem user’s system, in KMail, right-click on the “Local Folders” at the top of the left-hand pane → select “Account Settings” –

  • There should be a field on the Maildir tab which points to the directory where the Local Folders should be located – usually “~/.local/share/local-mail” …

It is as you say. And in “my” desktop it is “~/.local/share/local-mail” . In my wife’s one it is “~/.local/share/akonadi_maildir_resource_0/”.
I am almost sure (but haven’t take a note of this) that both systems do not have exactly the same installation starting point (and online upgrades afterwards). Thus it could be that the default place was “~/.local/share/local-mail” earlier and changed to the other one later.

In any case, thanks for pointing out the place where one can see (and change it, what I will not do). That side path of the problem is solved for me.

I am using kmail since 2 decades. One of its major annoyances is the ever changing default path to the local folders without notification. Current maildir resource uses /home/karl/.local/share/local-mail/ Adding a new maildir resource currently results in default path /home/karl/.local/share/akonadi_maildir_resource_27. lol!

** kmail actions are strictly linked to the file system names in the default path** such as /home/karl/.local/share/local-mail/trash (more in #7](https://forums.opensuse.org/showthread.php/558069-Kmail-trash-map-lost-it-s-trash-functionality?p=3056421#post3056421)). Users may turn off display names using the invocation ‘LANG=C kmail’. Kmail will then display ‘trash’ instead of ‘Prullebak’.

Changes to the local folder tree may result from inadvertent actions of the akonadi agents. Beware: Undo the changes by closing all applications involved and moving directories using bash commands.

OK, as you say annoyances, but as long as it works and I can find the place, I leave that as it is.

I have seen how the mail folders are mirrored in the directory structure, e.g. by using .<directoryname>.directory to have the sub-directories/folders. But I ahve no need (and I did not aks for) undoing the transalation. I was only wondering which of those are translated and why. I have e.g. a subfolder named Fietsersbond. Why does Kmail not try to translate this into Dutch? And why does it translate Thrash into Dutch? I can make some guesses, but I want to KNOW.

That is all understood, and I thought I expressed that earlier. My question is, when I move that trash directory to the place I want, is it then still noted as being the Trash directory? It must have some special parameters making it as such somewhere.

Presuming you created Fietsersbond voluntarily it has no attributes set. Thus there is no display name and kmail shows the system file name.

And why does it translate Thrash into Dutch? I can make some guesses, but I want to KNOW.

By default special folder trash, auto generated when creating kmail maildir ressource, has attributes set and a localized folder name is displayed e.g.: attribute name = ENTITYDISPLAY attribute value = (“Papierkorb” “user-trash” “” ())

My question is, when I move that trash directory to the place I want, is it then still noted as being the Trash directory? It must have some special parameters making it as such somewhere.

I moved folder trash from default position /home/tester/.local/share/local-mail/trash/ to /home/tester/.local/share/local-mail/Test/trash/ As a result kmail created a new /home/tester/.local/share/local-mail/trash/ and /home/tester/.local/share/local-mail/Test/trash/ isn’t displayed at all.

That is what I am asking for all the time. BUT WHERE ARE THOSE atributes???

akonadiconsole > DB Browser > collectionattributetable :wink:

https://techbase.kde.org/KDE_PIM/Akonadi/Development_Tools

That isn’t to be found simply in a file?

Akonadi Console is a tool for developers working with Akonadi or on Akonadi itself.

I do not think that is something an end-user should try. And not even a system manager.

.local/share/akonadi/db_data/akonadi/collectionattributetable.ibd

I do not think that is something an end-user should try. And not even a system manager.

Information is stored in database tables. Users do have options for browsing data. And they do have options for changing data. If you don’t like them keep off.

Thanks for that. Thus they have hidden that into a database file, then that database turns out to be unreliable and ruins the KMail folder structure (the very fact that this is NOT something an end-user can change by incident because it is in the database without easy access to the values, proves this IMHO). And there is thus no easy means (by moving a folder with the mouse to the place wanted) to repair it.

>:(

Which means, that, the only reliable way to setup Kontact/KMail/Akonadi reliably is –

  • To make sure that you have recent archives.
  • If possible, archive everything.
  • Start with a fresh user.
  • Set up KMail, and then, the rest of the Kontact components.
  • Restore the archives to KMail and then, the rest of the Kontact components … >:)

Looks like a very MS Windows way of working: start all over again.

My wife can live with the Trash on that strange place as long as she can see it. So we leave it as it is now. Until the next time that KMail moves it somewhere out of it’s own whim. :frowning:

Not satisfying at all of course.

A less annoying procedure (see end of post #10):

  1. quit kmail and stop akonadi
  2. run ‘mv trash trash.save’
  3. start kmail (this will create a new empty trash)
  4. move contents of trash.save to trash, using ‘mv trash.save/cur/* trash/cur’ and ‘mv trash.save/new/* trash/new’
  5. delete empty trash.save