[Akonadi] [Bug 336581] accidental database loss causes Akonadi / KMail to silently break correct folder assignments

[Martin Steigerwald]

https://bugs.kde.org/show_bug.cgi?id=336581

Martin Steigerwald <Martin at Lichtvoll.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|Compiled Sources            |Debian unstable
            Version|GIT (master)                |5.2.3

--- Comment #10 from Martin Steigerwald <Martin at Lichtvoll.de> ---
This is indeed still the case with KMail 5.2.3 (Debian Unstable unfortunately
does not have any newer packages due to the difficulty to properly package Qt
Webengine in order to enable newer KDEPIM versions, which likely means that
Debian will go with KDEPIM 16.04 for next stable version Stretch).

The principal issue of relying on database IDs outside of the database itself
and thus using wrong folders in case of a database loss, potentially causing
data loss, is still present.

For mailfilters:

~/.config> grep action- akonadi_mailfilter_agentrc | head -20
[…]
action-args-0=95
action-name-0=transfer
action-args-0=209
action-name-0=transfer
action-args-0=209
action-name-0=transfer
action-args-0=208
action-name-0=transfer
action-args-0=211
action-name-0=transfer
action-args-0=422
action-name-0=transfer

Action "transfer" means to move the mail into a folder. The corresponding
args-0 is the numerical id of the folder.

For folder settings:

~/.config> fgrep '[Folder-' kmail2rc | head
[Folder-1]
[Folder-10]
[Folder-100]
[Folder-101]
[Folder-102]
[Folder-103]
[Folder-104]
[Folder-105]
[Folder-106]
[Folder-107]

For default folders for mail identities:

~/.config> egrep -i "draft|template" emailidentities | head -10 
Drafts=21
Templates=31
Drafts=21
Templates=31
Drafts=21
Templates=31
Drafts=21
Templates=31
Drafts=411
Templates=378

Default inbox folder for POP mail resources:

martin at merkaba:~/.config> grep targetCollection akonadi_pop3_resource_0rc
targetCollection=361

I bet is similar for IMAP resources.


My expected result is this:

1) Either keep / rebuild / reassign references after a database loss properly
*or*

2) *loose* the references and require the user to reconfigure.

Yet *never ever* use *wrong* references, just do to a database loss.

Use a unique hash for identification, not just the index number of the database
entry. In that way you can at least *know* when the reference is no more valid.
*Or* store *all* of these reference into the database itself, so that they are
gone for good if the database is rebuilt.

For user convenience I would aim for approach 1 wherever possible which is
easier to do with a hash based approach. For maildir resource, you can store
the folder identification in the maildir filesystem, or IMAP it becomes more
difficult tough, yet you could at least also store the name and then if the
reference by hash is gone, you can show the folder name to the user and
possibly even autoselect it for confirmation.


You can argue that a database loss should not happen and with proper MariaDB
configuration, proper filesystem and proper storage media you might well be
right about that – *yet* in practice it did happen to a lot of users. So please
make Akonadi *failure proof* and more *robust* in cases like this.

Another approach would be to use something else than a database for metadata or
rethink the Akonadi caching concept completely like Aaron and others do with
Sink for Kubemail. I don´t see this happening for KMail from KDEPIM soon, so I
think it makes sense to make it more failure proof even before that may happen.

-- 
You are receiving this mail because:
You are the assignee for the bug.