One of my local K-mail folders (sent messages) shows an e-mail that seems corrupted.
Trying to archive this folder fails, any atempt to move, copy or delete the e-mail ends in a more or less extended error message (not able to exactly reproduce the behaviour). Afterwards, the system may be frozen forcing me to a hardware reset/reboot (I did not try to log on to text text console).
From what I memorize, the error messaeg in the extended version
stated some type of conflict making it impossible to retrieve the message from the backend (instance -1). It also stated a specific item number (3287 in collection 89) that has a dirty payload.
Has anybody an idea how to get rid of the corrupted item or how at least to
identify where it might be located?
It seems my installation of Akonadi uses a mysql databse for the meta-information.
In $HOME/.local/share/akonadi/file_db_data/
I found around 100 numbered directories containing what lokks like e-mails,
but was not able to identify 3287 in collection 89.
Is this the “real” local e-mail data or just a cache used by Akonadi?
I am using Kubuntu 22.04, KDE framwork 5.92.0, KDE-Plasma 5.24.7
Any help appreciated
Daniel
@dp-Kubuntu:
First – Welcome to the KDE Plasma Discuss Forum.
If it 's a local folder then, the e-mails are located in the directory tree ‘~/.local/share/.local-mail.directory/’ –
- Be aware that, there are “.” «hidden» sub-directories in this “hidden” local directory …
The directory ‘~/.local/share/local-mail/’ directory tree seems to be only a place-holder for the local mail directories.
The dirty payload can possibly dealt with by means of some Akonadi database housekeeping –
> akonadictl fsck 2>&1 | grep -iE 'found|no RID'
> akonadictl vacuum
> akonadictl fsck 2>&1 | grep -iE 'found|no RID'
After the “vacuum”, repeat the “fsck”.
If, “fsck” mentions that, it found something unpleasant and, that it had moved the offending item to “lost & found” then, the location it moved the offending object to is ‘~/.local/share/akonadi/file_lost+found/’ –
- Check the contents of of the “file_lost+found” directory with the CLI command “file” and then use “Kate” or whatever to view the e-Mail file contents – files containing e-Mail are text files …
Thank you very much for your quick reply.
As advised I checked for
~/.local/share/.local-mail.directory/
this path (hidden .local -mail-directory) does not exist in my system.
I again searched for any directories that seem to contain
e-mails and as stated in my first post, I only found
~/.local/share/akonadi/file_db_data/
As I have tried in the past and as has been suggested by you I again tried to use
akonadictl fsck
and
akonadictl vacuum.
A large number of items with missing RID
had been identified and seems that they had been moved
to
/.local/share/akonadi/file_lost+found/
No “dirty” items were or had been reported by
akonadictl fsck.
By chance I stumbled over file
.xsession-errors
where the original errors message was shown:
org.kde.pim.mailcommon: “Unable to fetch item from backend (collection -1) : Unable to retrieve item from resource: [LRCONFLICT] Resource akonadi_maildir_resource_0 tries to modify item 3287 () (in collection 89) with dirty payload, aborting STORE.”
Do you have any other idea, how to solve this issue?
Daniel
Open ‘~/.local/share/akonadi/file_lost+found/’ with Dolphin – you’ll notice if the “lost and found” file is an e-Mail or an Appointment or Task (VCS/ICS file) –
- Simply click on the file and follow the instructions –
In the case of an e-Mail, the contents will be displayed and then you can decide to reimport it or not.
In the case of an Appointment or Task, you’ll be asked if you want to add the item to an existing Calendar.
Thank you very much again for your answer,
however, I am not interested in restoring the e-mails in my lost and found folder.
My main problem still is, that my local “SENT” folder contains an
corrupted item that hinders this folder from being archived,
and I am still not able to move or to remove this item, nor am I able to identify
where this item has been stored.
Regards,
Daniel
You could try executing “file” on the contents of the local “Sent” directory.
The concerned directory is probably located under ‘~/.local/share/.local-mail.directory/’
If “file” reports that, a file is neither “news or mail” nor “MIME entity” and, “ASCII text” then, that file is probably the corrupted item you’re looking for.
Thank you for not giving up on this topic.
~/.local/share/.local-mail.directory/
just does not exist in my system.
The only directory that seems to contain e-mail date seems to be
~/.local/share/akonadi/file_db_data/
I am still not sure if this is “real” data, i am not sure, how this data is organized.
After spending way to much time I am giving on trying to understand how this akonadi-monster is supposed to work.
However, it seems I have found a work around:
After moving my local data to a certain directory I have been able to
archive apparently all local data (with exemption of the corrupted item).
After installing Akonadiconsole I was able to identify that data base collection 89 represented the local “sent” folder with just one remaining item with id 3287 (the id of the corrupted item). I used akonadiconsole to remove that item from the data base and that so far seems to have worked (although not really knowing, what I was doing).
In KMail, select Settings → Configure KMail…
- In “Accounts”, select the tab “Receiving” –
- Select “Local Folders” and then “Modify” –
- In the tab “Maildir” there’s a directory path which is usually ‘/home/«User»/.local/share/local-mail’ …
Take a look in that directory – there should be at least the directories ‘cur/’, ‘new/’ and ‘tmp/’ plus “inbox”, “drafts”, “outbox”, “sent-mail”, “templates” and “trash” plus, any local directories you’ve created …
Alternatively, take a look in the ‘~/.config/’ directory in the file ‘akonadi_maildir_resource_0rc’ –
> cat akonadi_maildir_resource_0rc
[General]
Path[$e]=$HOME/.local/share/local-mail
>
It seems that, you don’t have very much e-Mail in your Local Folders – KMail will create and use ‘$HOME/.local/share/.local-mail.directory/’ once a reasonable number of e-Mails are being stored locally.