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

[Christian Mollekopf]

Just to throw another idea in the room.

I agree the current situation is not ideal, but I'm also not sure if it is 
feasible to generate a globally unique id for every item (for performance 
reasons or simply because to much code already depends on the current id's).

Another solution would be to generate such an identifier for each akonadi 
database (upon initial creation), which can be used as a safeguard when using 
settings which rely on ids but are not stored in akonadi. Maybe this 
information is even already available (something like a creation date). Of 
course storing the settings in akonadi is preferable where possible.

That's not as ideal as having a globally unique id for every item, but we 
don't live in an ideal world and have to look for feasible solutions. 
Conceptually I would agree with you that the ideal solution would be to have a 
globally unique id for every item (i.e. as specified in 
http://tools.ietf.org/html/rfc4122).

Cheers,
Christian

On Thursday 15 December 2011 11.53:06 Sven Burmeister wrote:
> 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/
_______________________________________________
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/