[Kde-pim] Data loss: kmail2 must not use existing [Folder-xy] settings on random new folders

[Volker Krause]

First of all thanks for tracking down what actually happens here, this is very 
useful.

On Tuesday 13 December 2011 10:32:55 Sven Burmeister wrote:
> Let's start anew.
> 
> Removing akonadi's database must not lose any emails in any way.

I agree. I do however not agree with the assumptions that thus deleting the 
database is a supported use-case the entire setup has to recover from 
gracefully. Loss of the database is a catastrophic error that renders your 
entire client state useless, you have to start from scratch after that.

The system is designed to protect as much as possible of your payload data in 
this case (and with the exception of not yet written back changes, that 
actually works). The database however contains critical information for 
Akonadi to work, including the entire id mappings. The case you found (KMail 
expire settings) is one of the less common scenarios btw, resource change 
replay queues can potentially cause a much bigger damage if they operate based 
on invalid ids.

> Kmail is not an client for akonadi but currently the client.
> 
> Removing the database resets unique-IDs. Because their uniqueness does not
> rely on chance of re-occurence but database internals.

The uniqueness is guaranteed by the database, if you want ensure uniqueness 
across database loss you essentially start to create a second database for 
information that must not be lost, bringing us back to square one.

> Any client storing information cannot know whether akonadi has reset its
> database. This is a design-flaw IMHO if the ID is used to communicate.
> 
> Akonadi's unique-IDs are only unique for its database and not across the
> system. They do not even try to, yet are used outside akonadi.
> 
> Using these IDs outside akonadi is not robust, yet they are used outside
> causing data loss.
> 
> To reproduce:
> 
> 1. set some of your folders with expiration in kmail
> 2. close kmail
> 3. remove your akonadi database (it could have get corrupted, it might have
> grown too big, you name it, removing it must not lose any email.)

and you do not lose any email until this point, which is the only thing 
Akonadi tries to guarantee.

> 3. after you did so, restart akonadi and re-add your resources

That's where the real bug is, Akonadi tries too hard to recover from a 
catastrophic error (loss of database), without telling you to reset your 
setup.

> 4. start kmail
> 5. lose data
> 
> According to what you wrote there is no way kmail can know that the akonadi
> db was reset and thus it must assume that it can continue to use its
> settings for any ID it has stored.
> 
> This is neither failsafe nor robust.
> 
> What would make it more robust:
> 
> Use only IDs to communicate with clients that are "guaranteed" to be unique
> for akonadi _and_ the client, i.e. rely on chance of re-occurrence like
> message-IDs.
> 
> Generate a unique ID when creating a new akonadi database and require
> clients to check that ID every time they connect to akonadi. That way any
> client can compare the ID/db its settings apply to and remove them if a new
> database was created.
> 
> Please do not assume that removing akonadi's database is a corner case.

No, it is a catastrophic error scenario.

> Neither is it a corner case that clients store settings and rely on the
> "unique" ID they got from akonadi, which is only unique as long as akonadi
> is not reset.

Nevertheless, the already suggested approach of moving the folder settings 
from kmailrc into Akonadi collection properties makes sense anyway, for 
various other reasons as well.

regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20111215/6ac3733a/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/