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

[Sven Burmeister]

Am Dienstag, 13. Dezember 2011, 00:36:53 schrieb Kevin Krammer:
> > I do not agree that removing and adding resources is a corner case.
> 
> Neither do I.
> Removing collections should not make their ids available again.

If you remove the database how should akonadi know that kmail2 still hast 
"unique" IDs in usage that stem from the deleted database.

The new database will begin at 1 and kmail will continue to use the setting it 
already had for 1. If the ID was really unique, say "324FSSDF234S534" this 
would not happen. But 1 is not unique if mediated outside akonadi.

Another possibility would be that akonadi creates a unique id if it creates a 
new database. And all clients have to check first whether that unique id is 
still the same before they continue to use anything that relies on [Folder-xy] 
being unique.

> Looks like there is a bug in either the SQL statements that Akonadiserver
> uses to create its tables or in the database.
> 
> > Removing akonadis database either. In fact, it was advertised more than
> > once that akonadi's db is just a cache and removing it does not lose any
> > data. Well, now it does.
> 
> From what I read so far it did not.

Because there is no real unique id, expiration is applied to folders it was 
not set for and hence data is lost. This must not happen.

"3) Is there anything I might lose by deleting the database? Yes, there is, 
and that is the metadata added to your data. That can be anything extra 
information that cannot be stored in the format of your data, like Nepomuk 
tags or other custom information. In case of emails, you might think that 
read/forwarded/etc. can be lost. Luckily this is not the case (since KDE 
4.7.2), as the email storage formats can store these informations natively.

The above explains why you will not lose any critical information by losing 
your akonadi database."

Taken from http://blogs.kde.org/node/4503.

Please do not nitpick that one has to lose the db and restart kmail! Losing 
your db, adding resources back, starting kmail and you will lose data if you 
had expiration set to some folders.

> As I wrote before factors like limited resources make it necessary to
> iteratively migrate certain aspects of a setup. Having folder specific
> metadata in a specific client's config file instead of attached to the
> folder is a result of that.

The problem is that this is not only about settings. As soon as any client 
relies on simple (not even random) numbers being unique it will cause 
problems. Simply because akoandi's database can be deleted and thus the IDs 
lose their uniqueness.

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/