Summary: | search folders should not get updated on startup | ||
---|---|---|---|
Product: | [Unmaintained] kmail | Reporter: | Rainer Muehlhoff <r.muehlhoff> |
Component: | search | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED WAITINGFORINFO | ||
Severity: | wishlist | CC: | digital.alterego, kde, laidig, luigi.toscano, tropikhajma |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Rainer Muehlhoff
2004-06-28 15:49:43 UTC
> When starting kmail, it's seems to update the search folders, at > least if a day passed since I used kmail the last time. For I have > a very big folder (4000 msgs) and searching is really slow, each > time I restart kmail (after a day or so) it is blocked for more > than a minuted and takes 100% cpu, which is annoying if the first > thing you want to do when starting you computer in the morning is > checking for new mail. If KMail exits abnormally then it will clear search folders and recreate them by starting searches. But this should only be done after an abnormal exit of KMail. It also shouldn't block KMail although it can make the GUI unpleasantly unresponsive. So the behavior you are describing is not expected. I have about half a dozen search folders that search my large KDE CVS folder that currently contains 133576 messages and no re-searching is done at KMail startup here. There must be some difference in the way your KMail/System is configured that is causing the behavior you are experiencing, determining what the difference is is a probably necessary prerequisite to fixing the problem. I don't have a foolproof method for determining what this key difference is. You could try closing and restarting KMail and seeing if the researching behavior is triggered. If the slow behavior isn't triggered then this may indicate the normal way you close KMail is the problem (e.g. session management killing KMail on KDE logout could be the problem) > Why doesn't kmail just keep a smart index which makes searching > much slower Yes we are working on that as an option, but there will be a downside in memory/drive space used. > or why doesn't it take care that a dearch folder is up > to date every time when kmail runs, then the contents of a search > folder could be written to hard disk when shutting down an jest get > reread when starting up. That's actually exactly what is done currently. But there is some fault tolerance built into the search folder implementation. Basically a failure is being detected at startup and KMail is working to recover from this failure. Don. Mhmm, I don't know if this is the same problem,but when I startup Kmail it takes minutes before it gets responsive again. The following messages are printed to the console gazillions of times (one msg for every email i suppose): kmail(32123)/kmail (storage internals) KMFolderMaildir::getDwString: KDE_fopen(abs_file= "/home/florian/.kde4/share/apps/kmail/mail/inbox/cur/1140771286.8652.sBihZ:2,RS" , "r+") == stream == 0xb42b970 kmail(32123)/kmail (storage internals) KMFolderMaildir::getDwString: fclose(mIndexStream = 0xb42b970 ) kmail(32123)/kmail (storage internals) KMFolderMaildir::getDwString: KDE_fopen(abs_file= "/home/florian/.kde4/share/apps/kmail/mail/inbox/cur/1140776402.8107.D5rCM:2,S" , "r+") == stream == 0xb42f9b8 kmail(32123)/kmail (storage internals) KMFolderMaildir::getDwString: fclose(mIndexStream = 0xb42f9b8 ) kmail(32123)/kmail (storage internals) KMFolderMaildir::getDwString: KDE_fopen(abs_file= "/home/florian/.kde4/share/apps/kmail/mail/inbox/cur/1140778998.8107.qhAkM:2,S" , "r+") == stream == 0xb42f710 kmail(32123)/kmail (storage internals) KMFolderMaildir::getDwString: fclose(mIndexStream = 0xb42f710 ) KDE 4.2.1 from KDE-Mod Arch packages 186536 is a duplicate of this one I can't believe I'm hitting 5 years old bug I really don't care about any search folders, all I care is how long it takes before I'm able to work after clicking the mail icon. With thunderbird it's 5 seconds, with kmail it's 1 hour 20 minutes *** Bug 186536 has been marked as a duplicate of this bug. *** I also just found out that this is why KMail always took a few minutes before becoming usable after startup. However, I didn't have any saved searches, it was just doing the last search again and again. I didn't see any way in the UI to access that search again, in fact except for kDebug messages it wasn't even visible what KMail was doing all the time. Deleting ".kde/share/apps/kmail/search/Last Search" helped. :) The Last Search file contained this: [Search Folder] Base= Recursive=true contentsA=somesearchstring fieldA=<any header> funcA=contains name=<unknown> operator=and rules=1 *** This bug has been confirmed by popular vote. *** Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding. Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2. |