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

[Sven Burmeister]

Am Donnerstag, 15. Dezember 2011, 09:27:04 schrieb Volker Krause:
> First of all thanks for tracking down what actually happens here, this is
> very useful.

Don't mention it.

> 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.

No. Creating a real unique id would minimise the chances of re-occurrence, so 
in theory, even if you would create a million databases no id would re-appear. 
No need for a second database.

But as already suggested, this is not even needed if there is only a single 
real unique id, i.e. as unique as message ids are. Any client can store that 
id the first time it accesses akonadi or even prefix its configs with it and 
compare it on each following re-connect.

So in a way akonadi would supply a unique prefix to all its pseudo-unique ids.

> 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.

Which is why I suggested to create a real unique id when creating akonadi's 
database in order to allow any client to check whether the database changed. 
Store that unique-id in the database and as soon as the database is replaced 
the unique-id will change as well.

This does not make it as robust as it would be with real unique ids, i.e. a 
user can still empty akonadi's db manually – but that really is a croner case 
IMHO.

> No, it is a catastrophic error scenario.

You might not like to hear this but if akonadi suggests on wikis etc. that 
killing its db will not lose any email, erasing the database will be seen as 
ok and used as soon as something is not working, i.e. to check whether it got 
corrupted. People do the same with nepomuk or amarok databases. IMHO it does 
not make sense to discuss how wrong this is, but it does make sense to avoid 
any data loss even in that case. Even more so if it is as easy as creating one 
single unique id and making it available to clients.

> 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.

It does not solve all problems though. Filters would e.g. still point to the 
wrong folder which might be the trash being emptied on kmail close or some 
public imap folder. And there might be more scenarios I did not yet come 
across. All of which can be solved by adding a single unique ID to akonadi's 
database and making it available to clients for comparison.

Sven
_______________________________________________
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/