[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-pim
Subject: Re: [Kde-pim] Data loss: kmail2 must not use existing [Folder-xy]
From: Sven Burmeister <sven.burmeister () gmx ! net>
Date: 2011-12-16 11:16:51
Message-ID: 2498511.HQ0AVa0Vp0 () linux-ydd0 ! site
[Download RAW message or body]
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@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic