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

[Sven Burmeister]

I'll mix two emails here:

Am Freitag, 16. Dezember 2011, 09:13:46 schrieb Volker Krause:
> Adding extra safety checks that disable Akonadi in this case until the user 
> deleted all relevant files to start from scratch has much smaller impact and 
> would address your scenario just as fine (even if way less convenient),
> right?

Either I misunderstood you or it does not. :) Let's say the database is gone, 
badblocks, removed by mistake, removed on purpose, removed because its 
corruption cannot be fixed and since it only contains status info the work to 
put into partial recovery is just not worth the trouble. (Isn't this a bit 
like re-creating the index files for mbox which was suggested and even a 
contect-menu in former versions of kmail1)

How would akonadi know that a client still has some configs/data that will 
cause trouble? Since keeping a list of clients and their potential configs 
cannot be what you suggest I think I misunderstood.

Even if it did know this would mean that users would have to remove e.g. their 
kmail2rc or even better edit it. I'm not sure that's better than providing a 
simple unique id.

How would akonadi know that its database has been re-created if everything 
from ~/.config is gone?

That's why I suggested to put the check into the client, because the client 
knows best if he needs that check and what to do if it fails or if it's even 
worth using that unique id as prefix for configs etc.

> I'd also be willing to accept an UIDVALIDITY-like approach if there's a way
> to do this in the client lib only, not requiring modification of all
> applications (thus obviously limited to detection rather than automatic
> recovery), the impact of that should be manageable, and it avoids risky
> config migrations.

Automatic recovery would be nice but sounds way more complicated than the 
first step towards it, i.e.detecting a corruption or removal. And since 
removing the database should only lose status data and not emails, removal 
might be the easier solution for most users anyway. So holding back the db 
unique id check until an automatic recovery functionality has been implemented 
does not sound sensible to me.

It's true that if akonadi offers a validity check all applications using 
akonadi would have to add code in order to use it.

Yet first of all it increases data security so it should be worth it. Second, 
applications add code all the time, Laurent added code to check whether the db 
has been re-generated (while kmail is running) within hours. I bet that if 
akonadi would have offered that unique id per db he would have added the check 
instead.

> Adding just that identifier is trivial, using it all over the place (like
> proposed as a config file/key prefix for example) is the part I'm not happy
> with.

Applications have a choice. Since akonadi would only offer the choice of using 
the unique id.

1. Do nothing. Since the check is not something enforced, no need to add code.

2. Simplest approach, implement only a call to akonadi to check whether the db 
has changed and do not use any config that could cause trouble if that's true. 
This should be easy and improves the situation.

3. Anything from here is optional. sing whatever unique id as prefix for 
configs etc. might be a nicer approach but not necessary. Checking the one 
unique id would already be enough and certainly not a lot of code to add.

4. Implement functionality to try to match the existing config for the old db 
with the new db, e.g. try to find the folder for filter destination within the 
new db etc.

Don't apps get some info which version of the akonadiserver they are talking 
to? Could the db unique id not be put into that info?

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/