Re: [trinity-users] kmail, next update request?

On Friday 11 January 2019 10:21:43 Stefan Krusche wrote: Well, I just had htop send a terminate to the highest process # of 5 copies of kmail it can see. Killed it all. Restarted it from the tde most popular app list, see 2 copies running with both useing some cpu. and it reports the same bad index for one folder at restart. At this point I see 2 copies of kmail running, but when it has rebuilt the index for the emc directory, which currently holds a bit north of 58k messages, then I see 5 copies running, but only the first copy is actually showing cpu time. And its resurrecting read messages as new, unread. I can cycle thru them, reducing the unread count to zero, but then go to another list, and come back after having read its unread, and by then this folder has the same 3 (could be 40+) that I've already read and replied to, are once again marked unread. I've checked perms and such but I own the whole several gigabyte corpus of email, so I can't point any fingers at that for a cause. So whats doing it? This has been over the years, an ongoing problem when the number of messages in a given directory is in the modulo 60000 range. I have another list thats nearly 130k messages, gave me an identical problem for about a month about 18 months back. Then it got well, and hasn't done it in quite a spell now. Note that I abuse kmail a bit, I do have a procmail recipe or 3 that put bad stuff directly in the spam folder, and an sa-learn script that cleans out the spam-hold directory, feeds the spam to sa-learn and then moves the spam to a spam-hold folder that I review daily in case I want to rescue something miss-filed, so I am used to a spam and spam-hold index's needing a rebuild, but thats rarely more than 10 messages in either folder so that pair of indices being rebuilt is only a second or so Now this started up about a week ago. And I thought maybe this was a good time to see if we can spot the rat somehow. Cheers, Gene Heskett --