https://bugs.kde.org/show_bug.cgi?id=360834
Llyw <llyw.li...@coders-haven.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |llyw.li...@coders-haven.net
--- Comment #11 from Llyw <llyw.li...@coders-haven.net> ---
I would also appreciate it if the developers could follow up on this bug report
and agree that its importance should be elevated.
In essence this bug reports that what was supposed to be a data cache is
actually also a data storage. As a result deleting entries without a remote ID
can lead to data loss that is only recoverable if a backup of
~/.local/share/akonadi exists. Such a design error must be corrected and a
mechanism must be implemented that flushes this cached data to the associated
remote storage.
I myself currently have 422 entries in the pimitemtable without a remoteId
entry, all of which seem to be emails according to the associated parttable
entries with the data column for those entries that are of partTypeId 2
(RFC822) either being the actual contents of the email or the filename of a
file in ~/.local/share/akonadi/file_db_data, which in turn contains the email.
(The entry of partTypeId 3 (HEAD) always stores the corresponding email header
as plain text in the data column.) I have manually verified for some of these
emails that they are indeed not present in
~/.local/share/.local-mail.directory, so if I were to delete those entries
without a remote ID I would actually lose all those emails as those are POP3
accounts.
This is only made worse by the fact that people seem to propagate the deletion
of (all) PIM items without a remote ID as a way of cleaning/repairing the
database, see discussion in
https://forum.kde.org/viewtopic.php?f=215&t=138233&start=45#p381343. For items,
which are duplicates of items with remote storage, this seems to actually
resolve problems, see
https://forum.kde.org/viewtopic.php?f=215&t=171121#p449145 and note that this
suggestion is also part of the official trouble shooting guide
https://docs.kde.org/trunk5/en/kmail/kmail2/resource-conflict-error.html
(assuming that this is still up-to-date, of course), but there appears to be no
way to automatically determine which entries are ghosts and which are unique
data whose deletion results in data loss.
The only good news is that when archiving a folder PIM items with NULL remote
ID also appear to be included in the resulting archive, so it should still be
possible to export all emails. (This way one could migrate to another email
client if one does not wish to work with the software in its current state...)
--
You are receiving this mail because:
You are watching all bug changes.
