Bug 288792

Summary:	data loss: kmail2 must not use existing [Folder-xy] settings on random new folders
Product:	[Frameworks and Libraries] Akonadi	Reporter:	S. Burmeister <sven.burmeister>
Component:	general	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	critical	CC:	martin, montel, nalvarez, wstephenson
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:	4.8
Sentry Crash Report:

Description S. Burmeister 2011-12-12 12:08:11 UTC

Version:           unspecified (using KDE 4.7.2) 
OS:                Linux

If this is more of an akonadi issue please re-assign.

If one removes a resource kmail2rc keeps its [Folder-xy] settings including expiration settings. If one adds a new resource kmail2 will re-use those settings for the new folders.

This means that some folder of the new resource is expired although the user never set any expiration for it and hence loses data.

Kmail keeping old settings or to be more precise, not using unique-IDs for folders does also result in filters filtering to wrong folders instead of having no destination because the destination folder was removed and the new one just happens to get the same number when a new resource was added.

Reproducible: Didn't try

Steps to Reproduce:
Have lots of folders in different resources.
Check kmail2rc and its [Folder-xy] settings
Remove a resource via systemsettings > personal information while kmail2 is not running
Add another resource with different but the same number of folders


Actual Results:  
Open kmail2 and see that it happily applies the settings for the old folders to the new resource.

Expected Results:  
Never ever use folder settings on a folder they do not belong to.
Use unique IDs or something else to guarantee that this does not happen

Comment 1 Laurent Montel 2011-12-16 10:45:24 UTC

Expiration attribute was migrated to akonadi now.
For other fix I think that it's not really a kmail bug but perhaps a fix to akonadi to do.

Comment 2 S. Burmeister 2011-12-16 11:21:14 UTC

(In reply to comment #1)
> Expiration attribute was migrated to akonadi now.
> For other fix I think that it's not really a kmail bug but perhaps a fix to
> akonadi to do.

Absolutely! Thanks for fixing the kmail bit that quickly!

This is fixed in 4.8 only, right?

For reference: http://lists.kde.org/?l=kde-pim&m=132402345419985&w=2 is the thread that discusses how to solve the akonadi side.

Comment 3 Laurent Montel 2011-12-16 11:35:11 UTC

Yes just 4.8.

Comment 4 Martin Fahrendorf 2012-01-07 09:40:46 UTC

The same problem occurs if you have set folders for trash, draft, template and sent and loose/remove akonadi DB. The settins are reused for totally different folders. Most likely this does not loose Mails (but I am not sure if cleanup trash at exit clears the wrong folder then).

So is it fixed for this as well?

Comment 5 S. Burmeister 2012-01-07 12:07:20 UTC

Since only the kmail2 bit was fixed this bug needs to be re-opened and re-assigned to akonadi.

http://lists.kde.org/?l=kde-pim&m=132368796708381&w=2 is the mailinglist thread that discusses this issue.

Comment 6 Nicolás Alvarez 2012-01-07 20:00:56 UTC

Reassigning to akonadi (as requested by rabauke on IRC). I don't know what the component should be though.

Comment 7 Denis Kurz 2016-09-24 20:38:31 UTC

This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.

Comment 8 Denis Kurz 2017-01-07 22:09:13 UTC

Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.