Version: 1.8.91 (using KDE 3.4.91 (beta1, >= 20050910), compiled sources) Compiler: gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42) OS: Linux (i686) release 2.4.21-20.ELsmp Setting the above property has the desired result, but over a restart the property setting seems to be lost. In may cases the restart is due to a crash of kontact on kmail activities - maybe the property is only saved on clean exit...? It does seem to be saved on clean restarts (no crash), but the setting seems to be lost again after a crash restart.
It happens only after a crash, but doesn't happen after all crashes. The expiry and identity settings are lost too at the same time, for the same folders. While I understand that there isn't much we can do for fixing things a crash breaks, it's quite annoying to go through 50 mail folders resetting the identity and expiry settings. If anything can be done to improve this behaviour, it would be most welcome.
Forgot to confirm and to say it happens for non-IMAP folders as well.
On Thursday 27 October 2005 01:36, Allen Winter wrote: > On Wednesday 26 October 2005 08:08, Martin Koller wrote: > > On Friday 21 October 2005 22:40, Adriaan de Groot wrote: > > > On Friday 21 October 2005 17:28, Allen Winter wrote: > > > > 1. Kmail folder properties (esp. the Act on new/unread.. and > > > > Keep replies) get set/reset strangely by themselves. > > > > > > Get this every time KMail is kill -TERM'ed, yup; most folders > > > lose their 'act on new' setting. And kill -TERM happens often, > > > because kmail hangs on me regularly and I haven't been able to > > > track down why. > > > > I think I have a fix for this (attached). > > > > A little description of what I found: > > > > Whenever the folder-properties dialog is closed, writeConfig() is > > called, which results in kmailrc only holding (for this folder) > > the setting isOpen = true > > > > The rest of the setting are only stored to disk, when you change > > to another folder. > > > > When now you kill kmail before the rest is written, then > > obviously some defaults are used the next time ... (which means, > > about 40 (!) settings are lost) > > > > isOpen = true is created from > > KMFolderTree::writeIsListViewItemOpen(..) > > > > I don't know how this whole KConfig stuff is supposed to work, > > but what I did is, I added here a call to > > folder->storage()->writeConfig(); which is also done in the > > FolderDiaGeneralTab::save() method. > > > > I don't know why the rest of the settings are not written when > > isOpen is written, but at least the patch solves the problem ... > > > > OK to commit ? I see this got committed. > I applied your patch locally in my sandbox and it seems to work for > me. I changed a couple folder properties, then ran kill -TERM > `pidof kontact` and when I restarted kontact the changed properties > where still there. And then reverted. "The previous commit was done too fast, as Ingo already fixed it the right way ..." But I guess if the bug is fixed then 115464 can be closed, no? Don Sanders.
*** Bug 115561 has been marked as a duplicate of this bug. ***
Is this bug really fixed in 3.5 release? I can't confirm that. I set my lkml mail folder to delete mails older than 35 days, but after a "crash" (kontact couldn't access std.vcf) the setting is lost again.
Reopen bug due to request by user.
This bug is still present in kmail 1.9.1/KDE 3.5.1 on FreeBSD.
I can confirm this bug on gentoo with kmail 1.9.1 either.
Problem still not fixed in kmail 1.9.4 with KDE 3.5.4. As kmail crashes very often when I log out, my settings are lost almost at each session (it's a silent crash : no kcrash).
Does this still happen with kde4?
Work fine here