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

[Sven Burmeister]

Am Donnerstag, 15. Dezember 2011, 14:49:18 schrieb Volker Krause:
> Something like UIDVALIDITY in IMAP, yes that would work. However, it
> requires persistent storage that the user does not randomly delete. So far
> we assume that the database, but that's apparently not good enough.

If the unique id is in the database the only way to delete it from that 
database is by removing the database, which is no problem because in that case 
a new one would be needed anyway. The only other way is to use a mysql client 
and manipulate the db. That is of course possible but…

> So manipulating the database is a corner case, deleting it isn't? Doesn't
> make sense to me,

…every user is able to delete a file/database. Using sql or a sql-client to 
open akonadi's db and manipulate it is something completely different. Thus I 
still think that my statement does make sense and is consistent.

If the user removes the id stored in the client there is no harm either 
because to the client that's like akonadi just created a new db and hence it 
will not use any configs that rely on akonadi's database.

> Deleting random data as a diagnostic method? Come on, if that's really what
> our wikis are suggesting, then that's the high priority bug we need to
> address ASAP.

People are easily fed-up with not working PIM and thus do stupid things. There 
was a time when even removing .kde was a quite common suggestion on 
mailinglists and forums. Anyway, there is no point in discussing what people 
should not do. Losing the database has to be detectable by clients, currently 
this is not the case because they do not know whether the db they talked to 
last time is the same they do next time.

> If there are real use-cases we need to provide real solution for those.
> "It's too big" has been addressed by several changes for 1.7/4.8, and
> further optimizations exist as unfinished work branches. "Is it corrupted?"
> will also get some new diagnostics in 1.7, but can probably use some more
> work. Those are the only reasons I saw in this thread so far, what else do
> you have in mind?

I'm not saying this is a valid way to debug etc. I'm just stating that users 
will do it, they do it with .kde and they do it with nepomuk etc.

So if there is an easy way to even prevent data loss if the user does 
something stupid or the db is corrupted, it should be done. Having a single 
unique ID to identify the db for a client seems feasible to me and it would 
prevent data loss in all cases, even in those where users act "stupid".

> I am very reluctant to add extra complexity for the common use case just to
> protect people that insist on doing something you are not supposed to be
> doing.

Please don't get me wrong but I'll have to state this in a very simple way to 
make sure it's clear. I even thought about skipping all the other answers 
because you seem to side-line and find excuses regarding the main issue.

The database can get corrupted in a non-fixable way even if the user is not at 
fault. This equals removing the database. Hence it is a fact that that a 
removed database is a valid scenario and it does not make sense to discuss 
about what can lead to that scenario.

Currently that scenario is not handled gracefully and can even lead to data 
loss.

To prevent this clients have to be able to check whether the database they 
access is the same their configs etc. apply to.

I don't care what solution is taken. If there are better ideas, I'm all for 
it.

> Sure, the part I'm most worried about in this scenario are the change replay
> queues anyway, filters and expiry are harmless corner cases compared to
> that.

Losing email is not harmless and as I showed this can happen with either 
expire or filters pointing to the trash by mistake.

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/