trinity-users@lists.pearsoncomputing.net

Message: previous - next
Month: December 2019

my KMail problems, continued

From: Gene Heskett <gheskett@...>
Date: Sat, 7 Dec 2019 06:00:56 -0500
Since my kmail problems seem to be both legendary and generally ignored, 
I have based my attempted fixes, which so far have only managed to fix 
it for a week at most.

And I thought 2 weeks ago I had found a fix, but then the motherboard 
caught fire at one of the usb to back panel headers, requiring a fire 
extinguisher]s services and stinking up the place something awful.
S9 as of last evening, a new mobo, cpu is now a 9nth gen core i5 with 6 
cores running at 3.7 GHz and more memory, from 8 to 32GB, yadda yadda 
has given kmail a brand new playpen to raise hell in.  Which is exactly 
what its doing, bounceing from core to core, using 87% to 100% of 
whichever core it running on at this second.

A brief description seems to be that it is continuously regenerating the 
index files forever, burning up a core of the cpu forever. I say burning 
up somewhat tongue-in-check as I bought the biggest cpu cooler that 
didn't need water, and its running maybe 3 degrees above room temp.

This I assume includes the sorted lists.  But because this corpus of 
email has been copied and recopied so many times, and the copy creation 
is faster than the time granularity of the sort, the sort is never 
satisfied so it goes on forever.

What I'd like to do is ask linux to lie during one more copy operation, 
by having a script scan the header of the message for the oldest date, 
which likely is the date the message was rx'd here, and assign the 
filesystems creation date from that header date.  This would have the 
effect of restoreing the time differences it is sorting by such that 
there should not be 50 messages all sharing the same second in 2017 
creation date from the last copy operation which is the situation now.  
This of course is asking linux to lie as some of these messages are 20 
years older than their creation dates on the disk.

So, can it be done?  If so, how?  Or, can we change the sort date/time 
from linux's filesystem view, to the date/time contained in the messages 
header? This would slow the sort, a lot, but would restore the time 
granularity of the sort.

What say you?

Thanks.
  
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>