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
On Saturday 07 December 2019 05:00:56 am Gene Heskett wrote:
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.
Hi Gene,
Yup, can be done!
“grep” will let you find a date. "stat" will let you see a file's Access, Modify, Change, and Birth datetimes. “touch” will let you change Access and Modify datetimes.
The first Ref: gives a find loop to use. The second Ref: gives a (possibly risky) method to modify the Change time. Google for grep, tons of examples of that (and tons of ways to do the same thing with it)
Best, Michael
Ref: https://askubuntu.com/questions/62492/how-can-i-change-the-date-modified-cre... https://www.shellhacks.com/fake-file-access-modify-change-timestamps-linux/ https://www.thegeekstuff.com/2012/11/linux-touch-command/
On Saturday 07 December 2019 10:05:31 Michael wrote:
On Saturday 07 December 2019 05:00:56 am Gene Heskett wrote:
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.
Hi Gene,
Yup, can be done!
“grep” will let you find a date.
use bash to look at filename, grep -A2 for Received, grep -A2 for localhost, grep that for the 3rd line which will contain the arrival date in UTC -0500 format, at least for the qmail server at wdtv.com, I've had several mail access servers over the last 20 years including the infamous gmail since I switched from amigados to linux in 1998, never had a winbox here till earlier this year bought a cheap one to display the output of a redpitaya's VNA function.
"stat" will let you see a file's Access, Modify, Change, and Birth datetimes.
All of which would appear to be bogus for this use due to the several times its been copied en-mass, usually by mc.
But by using touch, the above derived date could be applied to the file, but which option modifies the all important creation date? Man touch doesn't appear to specifically cover that under the -D option, or am I looking at the wrong option?
Done with several elseif's and some break exits for when we have a grep hit, it could be done to each folders cur dir, even more than once because that header date as part of the file, is not volatile. And just as important, it could be done insitu on a live system. And the next time kmail gets around to re-indexing that dir, all the copy damage would be undone.
This would refresh my bash skills, which have been getting quite rusty as I've not written anything of note recently, like in 10 years.
“touch” will let you change Access and Modify datetimes.
Humm, but I want to modify the creation times, to make that equal arrival time from the date/time of arrival from $servername in the header. Even the pinfo version can only diddle access (atime) and modify time (mtime) but no mention of ctime is made. That sounds like I am screwed. Do we have anything which can diddle the ctime's?
The first Ref: gives a find loop to use. The second Ref: gives a (possibly risky) method to modify the Change time. Google for grep, tons of examples of that (and tons of ways to do the same thing with it)
Best, Michael
Ref: https://askubuntu.com/questions/62492/how-can-i-change-the-date-modifi ed-created-of-a-file https://www.shellhacks.com/fake-file-access-modify-change-timestamps-l inux/ https://www.thegeekstuff.com/2012/11/linux-touch-command/
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
On Sat, 7 Dec 2019 12:02:31 -0500 Gene Heskett gheskett@shentel.net wrote:
On Saturday 07 December 2019 10:05:31 Michael wrote:
“touch” will let you change Access and Modify datetimes.
Humm, but I want to modify the creation times, to make that equal arrival time from the date/time of arrival from $servername in the header. Even the pinfo version can only diddle access (atime) and modify time (mtime) but no mention of ctime is made. That sounds like I am screwed. Do we have anything which can diddle the ctime's?
From the look of it, it's intentionally difficult to modify on command. Calling chown on the file will set the ctime to the current time (even if the file's ownership isn't actually changed), so you can diddle the system time then do that. Most of the other methods seem to involve debugfs, virtual machines, and other exotica.
You know, if you don't need access to all of your old email constantly, you could just turn your mail directory into a symlink, split the last year or two of mail off into a separate directory from the older stuff and point the symlink there, and redirect the symlink if you need the older mail. Or split the older mail off into a separate user account. Because it really seems like you're going to a lot of trouble for very little return here.
E. Liddell
On Saturday 07 December 2019 18:11:26 E. Liddell wrote:
On Sat, 7 Dec 2019 12:02:31 -0500
Gene Heskett gheskett@shentel.net wrote:
On Saturday 07 December 2019 10:05:31 Michael wrote:
“touch” will let you change Access and Modify datetimes.
Humm, but I want to modify the creation times, to make that equal arrival time from the date/time of arrival from $servername in the header. Even the pinfo version can only diddle access (atime) and modify time (mtime) but no mention of ctime is made. That sounds like I am screwed. Do we have anything which can diddle the ctime's?
From the look of it, it's intentionally difficult to modify on command. Calling chown on the file will set the ctime to the current time (even if the file's ownership isn't actually changed), so you can diddle the system time then do that. Most of the other methods seem to involve debugfs, virtual machines, and other exotica.
You know, if you don't need access to all of your old email constantly, you could just turn your mail directory into a symlink, split the last year or two of mail off into a separate directory from the older stuff and point the symlink there, and redirect the symlink if you need the older mail. Or split the older mail off into a separate user account. Because it really seems like you're going to a lot of trouble for very little return here.
I'm forced to agree. But if I have to do that, its likely I'll just jump ship to claws or even (spit) t-bird. This has been bugging me off and on for at least 5 years, and I've been mostly ignored, sent hundreds of crash reports all to no avail as far as solving the problem is concerned. Paypal has no clue who Tim is, so I've not been able to contribute, which bothers the hell outta me as a firm believer in TANSTAAFL. Not having paid my dues, I don't feel like I can demand.
Wrong list, but can claws handle a 20+ gig corpus of email stretching back 20 years?
E. Liddell
Thanks, E. Lidell
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
On Saturday 07 December 2019 16:16:30 Gene Heskett wrote:
On Saturday 07 December 2019 18:11:26 E. Liddell wrote:
On Sat, 7 Dec 2019 12:02:31 -0500
Gene Heskett gheskett@shentel.net wrote:
On Saturday 07 December 2019 10:05:31 Michael wrote:
“touch” will let you change Access and Modify datetimes.
Humm, but I want to modify the creation times, to make that equal arrival time from the date/time of arrival from $servername in the header. Even the pinfo version can only diddle access (atime) and modify time (mtime) but no mention of ctime is made. That sounds like I am screwed. Do we have anything which can diddle the ctime's?
From the look of it, it's intentionally difficult to modify on command. Calling chown on the file will set the ctime to the current time (even if the file's ownership isn't actually changed), so you can diddle the system time then do that. Most of the other methods seem to involve debugfs, virtual machines, and other exotica.
You know, if you don't need access to all of your old email constantly, you could just turn your mail directory into a symlink, split the last year or two of mail off into a separate directory from the older stuff and point the symlink there, and redirect the symlink if you need the older mail. Or split the older mail off into a separate user account. Because it really seems like you're going to a lot of trouble for very little return here.
I'm forced to agree. But if I have to do that, its likely I'll just jump ship to claws or even (spit) t-bird. This has been bugging me off and on for at least 5 years, and I've been mostly ignored, sent hundreds of crash reports all to no avail as far as solving the problem is concerned. Paypal has no clue who Tim is, so I've not been able to contribute, which bothers the hell outta me as a firm believer in TANSTAAFL. Not having paid my dues, I don't feel like I can demand.
Wrong list, but can claws handle a 20+ gig corpus of email stretching back 20 years?
E. Liddell
Thanks, E. Lidell
Myself, I would archive the "really" old stuff (everything older than some arbitrary date). Put it somewhere safe, like on a separate drive, or at least in a separate folder, so that Kmail doesn't get into it.
Best guess is that it is just the size of your archive that is causing the problems. How often do you actually search back into your archives for an email older than, say, 6 months or a year past?
If you need to search the archives, deal with that problem as the need arises, rather than fighting this same losing battle, over and over, for little or no useful purpose.
By the way, I have used Claws and Sylpheed just a little. (I believe Sylpheed was forked from Claws, or the other way around.) I was interested in getting a cross-platform email client, so that I could use a portable app on a flash drive, if I am ever out and about. They work okay, but they lack the functionality of Kmail.
Bill
On Saturday 07 December 2019 21:05:09 William Morder via trinity-users wrote:
On Saturday 07 December 2019 16:16:30 Gene Heskett wrote:
On Saturday 07 December 2019 18:11:26 E. Liddell wrote:
On Sat, 7 Dec 2019 12:02:31 -0500
Gene Heskett gheskett@shentel.net wrote:
On Saturday 07 December 2019 10:05:31 Michael wrote:
“touch” will let you change Access and Modify datetimes.
Humm, but I want to modify the creation times, to make that equal arrival time from the date/time of arrival from $servername in the header. Even the pinfo version can only diddle access (atime) and modify time (mtime) but no mention of ctime is made. That sounds like I am screwed. Do we have anything which can diddle the ctime's?
From the look of it, it's intentionally difficult to modify on command. Calling chown on the file will set the ctime to the current time (even if the file's ownership isn't actually changed), so you can diddle the system time then do that. Most of the other methods seem to involve debugfs, virtual machines, and other exotica.
You know, if you don't need access to all of your old email constantly, you could just turn your mail directory into a symlink, split the last year or two of mail off into a separate directory from the older stuff and point the symlink there, and redirect the symlink if you need the older mail. Or split the older mail off into a separate user account. Because it really seems like you're going to a lot of trouble for very little return here.
I'm forced to agree. But if I have to do that, its likely I'll just jump ship to claws or even (spit) t-bird. This has been bugging me off and on for at least 5 years, and I've been mostly ignored, sent hundreds of crash reports all to no avail as far as solving the problem is concerned. Paypal has no clue who Tim is, so I've not been able to contribute, which bothers the hell outta me as a firm believer in TANSTAAFL. Not having paid my dues, I don't feel like I can demand.
Wrong list, but can claws handle a 20+ gig corpus of email stretching back 20 years?
E. Liddell
Thanks, E. Lidell
Myself, I would archive the "really" old stuff (everything older than some arbitrary date). Put it somewhere safe, like on a separate drive, or at least in a separate folder, so that Kmail doesn't get into it.
Best guess is that it is just the size of your archive that is causing the problems. How often do you actually search back into your archives for an email older than, say, 6 months or a year past?
Just this past week I went looking for something in the emc list, and found the msg in the folder for 2012. Thats admittedly a bit old, but it answered the question. Normal searches are usually hit in the same year as current.
If you need to search the archives, deal with that problem as the need arises, rather than fighting this same losing battle, over and over, for little or no useful purpose.
By the way, I have used Claws and Sylpheed just a little. (I believe Sylpheed was forked from Claws, or the other way around.) I was interested in getting a cross-platform email client, so that I could use a portable app on a flash drive, if I am ever out and about. They
work okay, but they lack the functionality of Kmail.
Thats been my impression also. And I think the problems with kmail are directly related to its 32 bit parentage. If someone were to go thru it and size every pointer or counter for a 64 bit system, I'd bet a case of your favorite suds this would all go away. But it might take 2 or 3 man/months to check and adjust it all. And THAT isn't going to be done just because those coders love it, they like eating and sleeping in warm houses etc too. Its past time we users spoke with our wallets again. Paypal has since improved their service, so I've got another hundred bucks to go with the hundred I tried to give the last time Tim asked for money. All I need is a paypal address that works.
Bill
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
On Saturday 07 December 2019 18:42:25 Gene Heskett wrote:
On Saturday 07 December 2019 21:05:09 William Morder via trinity-users
wrote:
On Saturday 07 December 2019 16:16:30 Gene Heskett wrote:
On Saturday 07 December 2019 18:11:26 E. Liddell wrote:
On Sat, 7 Dec 2019 12:02:31 -0500
Gene Heskett gheskett@shentel.net wrote:
On Saturday 07 December 2019 10:05:31 Michael wrote:
“touch” will let you change Access and Modify datetimes.
Humm, but I want to modify the creation times, to make that equal arrival time from the date/time of arrival from $servername in the header. Even the pinfo version can only diddle access (atime) and modify time (mtime) but no mention of ctime is made. That sounds like I am screwed. Do we have anything which can diddle the ctime's?
From the look of it, it's intentionally difficult to modify on command. Calling chown on the file will set the ctime to the current time (even if the file's ownership isn't actually changed), so you can diddle the system time then do that. Most of the other methods seem to involve debugfs, virtual machines, and other exotica.
You know, if you don't need access to all of your old email constantly, you could just turn your mail directory into a symlink, split the last year or two of mail off into a separate directory from the older stuff and point the symlink there, and redirect the symlink if you need the older mail. Or split the older mail off into a separate user account. Because it really seems like you're going to a lot of trouble for very little return here.
I'm forced to agree. But if I have to do that, its likely I'll just jump ship to claws or even (spit) t-bird. This has been bugging me off and on for at least 5 years, and I've been mostly ignored, sent hundreds of crash reports all to no avail as far as solving the problem is concerned. Paypal has no clue who Tim is, so I've not been able to contribute, which bothers the hell outta me as a firm believer in TANSTAAFL. Not having paid my dues, I don't feel like I can demand.
Wrong list, but can claws handle a 20+ gig corpus of email stretching back 20 years?
E. Liddell
Thanks, E. Lidell
Myself, I would archive the "really" old stuff (everything older than some arbitrary date). Put it somewhere safe, like on a separate drive, or at least in a separate folder, so that Kmail doesn't get into it.
Best guess is that it is just the size of your archive that is causing the problems. How often do you actually search back into your archives for an email older than, say, 6 months or a year past?
Just this past week I went looking for something in the emc list, and found the msg in the folder for 2012. Thats admittedly a bit old, but it answered the question. Normal searches are usually hit in the same year as current.
If you need to search the archives, deal with that problem as the need arises, rather than fighting this same losing battle, over and over, for little or no useful purpose.
By the way, I have used Claws and Sylpheed just a little. (I believe Sylpheed was forked from Claws, or the other way around.) I was interested in getting a cross-platform email client, so that I could use a portable app on a flash drive, if I am ever out and about. They
work okay, but they lack the functionality of Kmail.
Thats been my impression also. And I think the problems with kmail are directly related to its 32 bit parentage.
Due to a combination of weird circumstances, I am running 32-bit, so you could be right. But I intend to upgrade in the next few months, so that I can get into the latest Debian/Devuan releases, Buster, etc.
If someone were to go thru it and size every pointer or counter for a 64 bit system, I'd bet a case of your favorite suds this would all go away.
That would be Guinness Stout, either real draught (a keg, not in the cans), or the regular bottles. I am also aching to find Guinness (Russian) Imperial Stout. I hear it is really something.
Damn, now I will have to go out to get some Guinness, and I blame it all on you, Gene.
But it might take 2 or 3 man/months to check and adjust it all. And THAT isn't going to be done just because those coders love it, they like eating and sleeping in warm houses etc too. Its past time we users spoke with our wallets again. Paypal has since improved their service, so I've got another hundred bucks to go with the hundred I tried to give the last time Tim asked for money. All I need is a paypal address that works.
Cheers, Gene Heskett
Yup, I promised to send a donation for the Trinity project, and it is a point of honor, but now I am wondering where to send the money. I would prefer just to send a check (or cheque), or at least use my credit card, rather than PayPal.
Bill
On Saturday 07 December 2019 21:54:46 William Morder via trinity-users wrote:
On Saturday 07 December 2019 18:42:25 Gene Heskett wrote:
On Saturday 07 December 2019 21:05:09 William Morder via trinity-users
wrote:
[...]
Myself, I would archive the "really" old stuff (everything older than some arbitrary date). Put it somewhere safe, like on a separate drive, or at least in a separate folder, so that Kmail doesn't get into it.
Best guess is that it is just the size of your archive that is causing the problems. How often do you actually search back into your archives for an email older than, say, 6 months or a year past?
[...]
By the way, I have used Claws and Sylpheed just a little. (I believe Sylpheed was forked from Claws, or the other way around.) I was interested in getting a cross-platform email client, so that I could use a portable app on a flash drive, if I am ever out and about. They
work okay, but they lack the functionality of Kmail.
Thats been my impression also. And I think the problems with kmail are directly related to its 32 bit parentage.
Due to a combination of weird circumstances, I am running 32-bit, so you could be right. But I intend to upgrade in the next few months, so that I can get into the latest Debian/Devuan releases, Buster, etc.
If someone were to go thru it and size every pointer or counter for a 64 bit system, I'd bet a case of your favorite suds this would all go away.
That would be Guinness Stout, either real draught (a keg, not in the cans),
never from cans, too big a connection between the alu in the can and senior dementia/ aka alzheimers. I have drunk maybe a 12 pack out of a can in 85 years. That includes pop, I'll go thirsty first.
or the regular bottles. I am also aching to find Guinness (Russian) Imperial Stout. I hear it is really something.
Damn, now I will have to go out to get some Guinness, and I blame it all on you, Gene.
I claim it as a point of honor to drive someone to the well. Problem is, I can't join them since I am diabetic, and limit myself to one near beer a day. The funny part is that its 6:33 am here and half of last nights bottle of Miller 64 is still sitting here. Guinness takes a different taste I've never developed an urge for. I like my whiskey where you can still taste the corn in it. Black label Jack Daniels, but my last 5th was emptied 5 years ago. And took 5 years to empty it.
But it might take 2 or 3 man/months to check and adjust it all. And THAT isn't going to be done just because those coders love it, they like eating and sleeping in warm houses etc too. Its past time we users spoke with our wallets again. Paypal has since improved their service, so I've got another hundred bucks to go with the hundred I tried to give the last time Tim asked for money. All I need is a paypal address that works.
Cheers, Gene Heskett
Yup, I promised to send a donation for the Trinity project, and it is a point of honor, but now I am wondering where to send the money. I would prefer just to send a check (or cheque), or at least use my credit card, rather than PayPal.
Bill
Take care Bill.
Cheers, Gene Heskett
On Saturday 07 December 2019 21:54:46 William Morder via trinity-users wrote:
On Saturday 07 December 2019 18:42:25 Gene Heskett wrote:
On Saturday 07 December 2019 21:05:09 William Morder via trinity-users
wrote:
On Saturday 07 December 2019 16:16:30 Gene Heskett wrote:
On Saturday 07 December 2019 18:11:26 E. Liddell wrote:
On Sat, 7 Dec 2019 12:02:31 -0500
Gene Heskett gheskett@shentel.net wrote:
On Saturday 07 December 2019 10:05:31 Michael wrote: > “touch” will let you change Access and Modify datetimes.
Humm, but I want to modify the creation times, to make that equal arrival time from the date/time of arrival from $servername in the header. Even the pinfo version can only diddle access (atime) and modify time (mtime) but no mention of ctime is made. That sounds like I am screwed. Do we have anything which can diddle the ctime's?
From the look of it, it's intentionally difficult to modify on command. Calling chown on the file will set the ctime to the current time (even if the file's ownership isn't actually changed), so you can diddle the system time then do that. Most of the other methods seem to involve debugfs, virtual machines, and other exotica.
You know, if you don't need access to all of your old email constantly, you could just turn your mail directory into a symlink, split the last year or two of mail off into a separate directory from the older stuff and point the symlink there, and redirect the symlink if you need the older mail. Or split the older mail off into a separate user account. Because it really seems like you're going to a lot of trouble for very little return here.
I'm forced to agree. But if I have to do that, its likely I'll just jump ship to claws or even (spit) t-bird. This has been bugging me off and on for at least 5 years, and I've been mostly ignored, sent hundreds of crash reports all to no avail as far as solving the problem is concerned. Paypal has no clue who Tim is, so I've not been able to contribute, which bothers the hell outta me as a firm believer in TANSTAAFL. Not having paid my dues, I don't feel like I can demand.
Wrong list, but can claws handle a 20+ gig corpus of email stretching back 20 years?
E. Liddell
Thanks, E. Lidell
Myself, I would archive the "really" old stuff (everything older than some arbitrary date). Put it somewhere safe, like on a separate drive, or at least in a separate folder, so that Kmail doesn't get into it.
Best guess is that it is just the size of your archive that is causing the problems. How often do you actually search back into your archives for an email older than, say, 6 months or a year past?
Just this past week I went looking for something in the emc list, and found the msg in the folder for 2012. Thats admittedly a bit old, but it answered the question. Normal searches are usually hit in the same year as current.
If you need to search the archives, deal with that problem as the need arises, rather than fighting this same losing battle, over and over, for little or no useful purpose.
By the way, I have used Claws and Sylpheed just a little. (I believe Sylpheed was forked from Claws, or the other way around.) I was interested in getting a cross-platform email client, so that I could use a portable app on a flash drive, if I am ever out and about. They
work okay, but they lack the functionality of Kmail.
Thats been my impression also. And I think the problems with kmail are directly related to its 32 bit parentage.
Due to a combination of weird circumstances, I am running 32-bit, so you could be right. But I intend to upgrade in the next few months, so that I can get into the latest Debian/Devuan releases, Buster, etc.
If someone were to go thru it and size every pointer or counter for a 64 bit system, I'd bet a case of your favorite suds this would all go away.
That would be Guinness Stout, either real draught (a keg, not in the cans), or the regular bottles. I am also aching to find Guinness (Russian) Imperial Stout. I hear it is really something.
Damn, now I will have to go out to get some Guinness, and I blame it all on you, Gene.
But it might take 2 or 3 man/months to check and adjust it all. And THAT isn't going to be done just because those coders love it, they like eating and sleeping in warm houses etc too. Its past time we users spoke with our wallets again. Paypal has since improved their service, so I've got another hundred bucks to go with the hundred I tried to give the last time Tim asked for money. All I need is a paypal address that works.
Cheers, Gene Heskett
Yup, I promised to send a donation for the Trinity project, and it is a point of honor, but now I am wondering where to send the money. I would prefer just to send a check (or cheque), or at least use my credit card, rather than PayPal.
Bill
Before that I had stopped kmail, removed ALL index files and restarted kmail. Took it about 20 minutes to open a window and advise me 3 of the indices were old or missing, which they weren't. I let it run till I could see by the times that it was in the 3rd loop of rebuilding them.
So Just for S&G, I made an OldMail directory, and since the biggest index file was for debian-user list, and all the file dates were from thanksgiving day 2018 and newer. I moved anything dated before Jan 1 2019 into this invisible to kmail old directory. Before I was done, kmail suddenly decided the indexes were good and shut the reindexing off. And has not restarted. Yet that index file has not shrunk, so I'm going to kill it and restart kmail.
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
On Sunday 08 December 2019 14:34:34 Gene Heskett wrote:
[...]
I had stopped kmail, removed ALL index files and restarted kmail. Took it about 20 minutes to open a window and advise me 3 of the indices were old or missing, which they weren't. I let it run till I could see by the file times that it was in the 3rd loop of rebuilding them.
Some editing here to add detail
So Just for S&G, I made a /home/gene/OldMail directory, and since the biggest index file was for debian-user list at nearly 10 megabytes, and all the file dates were from thanksgiving day 2018 and newer, the last time I had copied it to a whole new Mail dir.
I moved anything dated before Jan 1 2019 into this invisible to kmail old directory. Before I was done, kmail suddenly decided the indexes were good and shut the reindexing off. And has not restarted. Yet that index file has not shrunk, so I'm going to kill it and restart kmail.
And this is weird as hell!, it regenerated the exact same file at its original date/time 35 minutes ago. Hogged a core at a time for 3 or 4 minutes before it opened the main gui, and then shut down the indexing again, acting normally. Go figure, I've used up my quota of disbelief for today. Might even start on my one a day beer before dinner. Time to go check on the missus, who didn't want any lunch at 13:00. Do Carry on.
Thanks all.
Cheers, Gene Heskett
Anno domini 2019 Sat, 7 Dec 18:05:09 -0800 William Morder via trinity-users scripsit:
[...] By the way, I have used Claws and Sylpheed just a little. (I believe Sylpheed was forked from Claws, or the other way around.) I was interested in getting a cross-platform email client, so that I could use a portable app on a flash drive, if I am ever out and about. They work okay, but they lack the functionality of Kmail.
Same here. Kmail is the reason why I'm so interested in TDE on FreeBSD. Tried Claws, but was not able to configure it in the way I liked. And Kmail and Claws mailformats are not exactly the same, so sharing Mails on different platforms is not easy :/
Bill
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 12/07/2019 06:16 PM, Gene Heskett wrote:
I'm forced to agree. But if I have to do that, its likely I'll just jump ship to claws or even (spit) t-bird. This has been bugging me off and on for at least 5 years, and I've been mostly ignored, sent hundreds of crash reports all to no avail as far as solving the problem is concerned. Paypal has no clue who Tim is, so I've not been able to contribute, which bothers the hell outta me as a firm believer in TANSTAAFL. Not having paid my dues, I don't feel like I can demand.
Yes,
I've followed on and off your kmail woes. From what you describe this is a bug that should be fixed. kmail should not continually be putting a load on the system resorting indexes, etc.. There should be debugging that can be cranked up to cause TDE to spit out INFO level messages for kmail that may give a better picture of what is going on.
If the problem is that your mail store is too big for kmail to handle without thinking it needs to reindex -- that's still a bug and whether it is a Qt3 issue or kmail issue, both should be solveable today. (just off hand I can see if a limit is INT_MAX how a 20G mail store would be an issue), Regardless, whatever it triggering the reindexing needs to be identified.
Whatever was burning up the cores on your old box -- is still causing the same mischief on your new box -- it's just doing a whole lot more mischief a whole lot faster now....
David C. Rankin wrote:
Yes,
I've followed on and off your kmail woes. From what you describe this is a bug that should be fixed. kmail should not continually be putting a load on the system resorting indexes, etc.. There should be debugging that can be cranked up to cause TDE to spit out INFO level messages for kmail that may give a better picture of what is going on.
If the problem is that your mail store is too big for kmail to handle without thinking it needs to reindex -- that's still a bug and whether it is a Qt3 issue or kmail issue, both should be solveable today. (just off hand I can see if a limit is INT_MAX how a 20G mail store would be an issue), Regardless, whatever it triggering the reindexing needs to be identified.
Whatever was burning up the cores on your old box -- is still causing the same mischief on your new box -- it's just doing a whole lot more mischief a whole lot faster now....
I also think his archive is too big and also I think he's touching mails directly or with something else, causing the reindexing, although only hypothesis.
It could be also a bug - but how can one reproduce it?
regards
On Sunday 08 December 2019 04:16:10 deloptes wrote:
David C. Rankin wrote:
Yes,
I've followed on and off your kmail woes. From what you describe this is a bug that should be fixed. kmail should not continually be putting a load on the system resorting indexes, etc.. There should be debugging that can be cranked up to cause TDE to spit out INFO level messages for kmail that may give a better picture of what is going on.
If the problem is that your mail store is too big for kmail to handle without thinking it needs to reindex -- that's still a bug and whether it is a Qt3 issue or kmail issue, both should be solveable today. (just off hand I can see if a limit is INT_MAX how a 20G mail store would be an issue), Regardless, whatever it triggering the reindexing needs to be identified.
Whatever was burning up the cores on your old box -- is still causing the same mischief on your new box -- it's just doing a whole lot more mischief a whole lot faster now....
I also think his archive is too big and also I think he's touching mails directly or with something else, causing the reindexing, although only hypothesis.
It could be also a bug - but how can one reproduce it?
regards
I manually drag and drop spam into a spam folder at random times using kmails own message mover. I have a cron script that stops fetchmail, and then runs sa-learn over that, and moves those 15 or less messages to another folder kmail can see called spam-hold, emptying it before the move so that stuff has an additional day to live in case I want it back.
That is the extent of _my_ putzing with its data.
That script: ============================== #!/bin/bash PATH=/sbin:/root/bin:/usr/bin:/bin:/home/gene/bin # make this run as gene! # make sure the database is free killall fetchmail # wait for the spamd pipes to drain sleep 20 # do this dastardly deed sa-learn --ham /home/gene/Mail/ham/cur sa-learn --ham /home/gene/Mail/coco/cur sa-learn --ham /home/gene/Mail/Xorg/cur sa-learn --spam /home/gene/Mail/spam/cur # now, this stuff is trash, 24 hours old, kill it. rm -f /home/gene/Mail/spam-hold/cur/* # And move todays catch into Mail/spam-hold/cur for a 24 hour period # so I can retrieve it the next day if needed. mv /home/gene/Mail/spam/cur/* /home/gene/Mail/spam-hold/cur/ # Note, I leave the ham for moving where it really goes # and restore fetchmail but let the disks synch first sleep 6 /usr/bin/fetchmail -d 120 --fetchmailrc /home/gene/.fetchmailrc ==============================
I don't see a thing there that kmail should get a tummy ache over. That script has been running daily for close to 20 years now. If fetchmail is running, incoming mail is handled automaticly by sending kmail a check mail message over the dcop or dbus message bus. All kmail has to do is retrieve anything procmail has put in /var/spool/mail/* and sort it to the correct folder. Since kmail is single-threaded, thats maybe a 200 ms freeze of the composer while it's doing that. The only independent thread seems to be the parent thread doing the indexing as killing it kills the other kmail instances seen by htop. 5 total, but the other 4 never record any cpu time.
Computers should save you work, not make it, so I write scripts to automate it.
Thank you deloptes.
Cheers, Gene Heskett
Gene Heskett wrote:
I don't see a thing there that kmail should get a tummy ache over. That script has been running daily for close to 20 years now. If fetchmail is running, incoming mail is handled automaticly by sending kmail a check mail message over the dcop or dbus message bus. All kmail has to do is retrieve anything procmail has put in /var/spool/mail/* and sort it to the correct folder. Since kmail is single-threaded, thats maybe a 200 ms freeze of the composer while it's doing that. The only independent thread seems to be the parent thread doing the indexing as killing it kills the other kmail instances seen by htop. 5 total, but the other 4 never record any cpu time.
Computers should save you work, not make it, so I write scripts to automate it.
Thank you deloptes.
Cheers, Gene Heskett
I don't know Gene. I am not sure it is single threaded - I use kontact - and I am not sure it is good idea to let it run on /var/spool/mail/*. I have stopped using this +10y ago. I do not remember why anymore. I have an IMAP - locally and on the ISP end. I am afraid your issue is too specific that someone can reproduce and debug it.
IF I were you, I would try to narrow down the problem - for example decouple the chain in your process and see where it goes crazy.
What I remember from the past is that I found out, that the IMAP Maildir should not be the KMail Maildir - but forgive me I was naive and unexperienced back then.
regards
On 12/08/2019 06:46 AM, Gene Heskett wrote:
I don't see a thing there that kmail should get a tummy ache over. That script has been running daily for close to 20 years now. If fetchmail is running, incoming mail is handled automaticly by sending kmail a check mail message over the dcop or dbus message bus. All kmail has to do is retrieve anything procmail has put in /var/spool/mail/* and sort it to the correct folder. Since kmail is single-threaded, thats maybe a 200 ms freeze of the composer while it's doing that. The only independent thread seems to be the parent thread doing the indexing as killing it kills the other kmail instances seen by htop. 5 total, but the other 4 never record any cpu time.
Computers should save you work, not make it, so I write scripts to automate it.
Thank you deloptes.
Cheers, Gene Heskett
I do the same thing with spamassassin but utilizing 4-folders:
spam spam-learn spam-probably spam-unlearn
where spamassassin drops potential spam in spam-probabaly. I look through it and move what is spam to spam-learn (where it is processed by sa-learn and moved to spam automatically) and move what isn't spam to spam-unlearn where unlearn is run on it and it is put back in the inbox.
The key here, and in your case, the movement of mail between folders should not be causing a reindexing of your entire mail store. If that is what is happening, then that is the bug that should be looked at and confirmed.
On Monday 09 December 2019 20:45:33 David C. Rankin wrote:
On 12/08/2019 06:46 AM, Gene Heskett wrote:
I don't see a thing there that kmail should get a tummy ache over. That script has been running daily for close to 20 years now. If fetchmail is running, incoming mail is handled automaticly by sending kmail a check mail message over the dcop or dbus message bus. All kmail has to do is retrieve anything procmail has put in /var/spool/mail/* and sort it to the correct folder. Since kmail is single-threaded, thats maybe a 200 ms freeze of the composer while it's doing that. The only independent thread seems to be the parent thread doing the indexing as killing it kills the other kmail instances seen by htop. 5 total, but the other 4 never record any cpu time.
Computers should save you work, not make it, so I write scripts to automate it.
Thank you deloptes.
Cheers, Gene Heskett
I do the same thing with spamassassin but utilizing 4-folders:
spam spam-learn spam-probably spam-unlearn
where spamassassin drops potential spam in spam-probabaly. I look through it and move what is spam to spam-learn (where it is processed by sa-learn and moved to spam automatically) and move what isn't spam to spam-unlearn where unlearn is run on it and it is put back in the inbox.
The key here, and in your case, the movement of mail between folders should not be causing a reindexing of your entire mail store. If that is what is happening, then that is the bug that should be looked at and confirmed.
Well, since this is kmail 1.9, mostly written in 32 bit days, and moving about half of the debian list to an out of kmail directory, the problem has not re-surfaced, so I am more than ever convinced its triggered by a 32 bit overflow someplace.
Where, I've no clue, but I suspect a concerted effort to bring it into the 64 bit world would pay stability dividends over the next several years.
Cheers, Gene Heskett
Gene Heskett wrote:
Well, since this is kmail 1.9, mostly written in 32 bit days, and moving about half of the debian list to an out of kmail directory, the problem has not re-surfaced, so I am more than ever convinced its triggered by a 32 bit overflow someplace.
Where, I've no clue, but I suspect a concerted effort to bring it into the 64 bit world would pay stability dividends over the next several years.
Might be - who knows - I looked over it - to understand, one needs the design document or some time to understand how kmail is working. As it is not a simple application the time needed is also not an hour or two.
However when you look at the properties of one directory - there is the option to enable/disable indexing. Have you seen this?
If your archive is not changing I guess also indexing is not needed there, but not sure.
On Tuesday 10 December 2019 14:47:12 deloptes wrote:
Gene Heskett wrote:
Well, since this is kmail 1.9, mostly written in 32 bit days, and moving about half of the debian list to an out of kmail directory, the problem has not re-surfaced, so I am more than ever convinced its triggered by a 32 bit overflow someplace.
Where, I've no clue, but I suspect a concerted effort to bring it into the 64 bit world would pay stability dividends over the next several years.
Might be - who knows - I looked over it - to understand, one needs the design document or some time to understand how kmail is working. As it is not a simple application the time needed is also not an hour or two.
I'm very well aware of that deloptes, having done it for important but broken code as published for a much simpler 6809 based platform in a previous life, and the student in question probably got an A from his imbecile prof!
Probably at least a month or more to begin to understand it. My thinker was then 35 years younger too, and noticeably more agile at "getting into someone else's head" than it would be today. But kmail wasn't written by anything but a committee of volunteers loosely herded (think cats) by Ingo Klocker, so there are probably in excess of 10 brains you've got to learn to think like in that code. Not a task that I at 85 want to touch with a good length of dry fiberglass pole. The fact that its stood on top of the hill for email agents as long as it has, says quite a bit for it in spite of the picky little problems we're having with it now. FWIW, I've used it since I built RH5.0 in about '98.
And since around 2003 I have always installed to a new drive, and copied the corpus over from the old drive, which is part of how I now have such a huge corpus of email. And drives with north of 200,000 spinning hours on them.
However when you look at the properties of one directory - there is the option to enable/disable indexing. Have you seen this?
No. KMail says its 1.9.10, from r14.0.6.
Where do you find that option?
Thanks deloptes.
If your archive is not changing I guess also indexing is not needed there, but not sure.
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
Gene Heskett wrote:
However when you look at the properties of one directory - there is the option to enable/disable indexing. Have you seen this?
No. KMail says its 1.9.10, from r14.0.6.
Where do you find that option?
Thanks deloptes.
Right Click on the Mail folder and go to settings or options and there you have on the General the indexing question.
The screenshot is in my language - not sure if it will help you, but still might give some light.
regards
On Tuesday 10 December 2019 17:33:29 deloptes wrote:
Gene Heskett wrote:
However when you look at the properties of one directory - there is the option to enable/disable indexing. Have you seen this?
No. KMail says its 1.9.10, from r14.0.6.
Where do you find that option?
Thanks deloptes.
Right Click on the Mail folder and go to settings or options and there you have on the General the indexing question.
The screenshot is in my language - not sure if it will help you, but still might give some light.
regards
This is obviously a different popup from what I am looking at.
Cheers, Gene Heskett
Anno domini 2019 Tue, 10 Dec 23:33:29 +0100 deloptes scripsit:
Gene Heskett wrote:
However when you look at the properties of one directory - there is the option to enable/disable indexing. Have you seen this?
No. KMail says its 1.9.10, from r14.0.6.
Where do you find that option?
Thanks deloptes.
Right Click on the Mail folder and go to settings or options and there you have on the General the indexing question.
The screenshot is in my language - not sure if it will help you, but still might give some light.
regards
Interesting, I don't see this option here. kmail is on 14.0.7~pre28-0, mail folders are maildir format.
Nik
On Wednesday 11 December 2019 02:53:32 am Dr. Nikolaus Klepp wrote:
Anno domini 2019 Tue, 10 Dec 23:33:29 +0100
deloptes scripsit:
Gene Heskett wrote:
However when you look at the properties of one directory - there is the option to enable/disable indexing. Have you seen this?
No. KMail says its 1.9.10, from r14.0.6.
Where do you find that option?
Right Click on the Mail folder and go to settings or options and there you have on the General the indexing question.
The screenshot is in my language - not sure if it will help you, but still might give some light.
Interesting, I don't see this option here. kmail is on 14.0.7~pre28-0, mail folders are maildir format.
Right Click on the folder >> Properties >> “Act on new/unread mail in this folder”
I will guess that disables indexing as well?
Anno domini 2019 Wed, 11 Dec 08:09:54 -0600 Michael scripsit:
On Wednesday 11 December 2019 02:53:32 am Dr. Nikolaus Klepp wrote:
Anno domini 2019 Tue, 10 Dec 23:33:29 +0100
deloptes scripsit:
Gene Heskett wrote:
However when you look at the properties of one directory - there is the option to enable/disable indexing. Have you seen this?
No. KMail says its 1.9.10, from r14.0.6.
Where do you find that option?
Right Click on the Mail folder and go to settings or options and there you have on the General the indexing question.
The screenshot is in my language - not sure if it will help you, but still might give some light.
Interesting, I don't see this option here. kmail is on 14.0.7~pre28-0, mail folders are maildir format.
Right Click on the folder >> Properties >> “Act on new/unread mail in this folder”
I will guess that disables indexing as well?
Hm, I always wondered what that option actually does.
Nik
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Dr. Nikolaus Klepp wrote:
Hm, I always wondered what that option actually does.
Nik
Hmm - could be "lost in translation" problem - because in my language it says "Indicate" or "Index" - not clear From what you write it means it is monitoring this directory for new messages, but if monitoring is disabled - could also disable re-indexing.
On Wednesday 11 December 2019 09:09:54 Michael wrote:
On Wednesday 11 December 2019 02:53:32 am Dr. Nikolaus Klepp wrote:
Anno domini 2019 Tue, 10 Dec 23:33:29 +0100
deloptes scripsit:
Gene Heskett wrote:
However when you look at the properties of one directory - there is the option to enable/disable indexing. Have you seen this?
No. KMail says its 1.9.10, from r14.0.6.
Where do you find that option?
Right Click on the Mail folder and go to settings or options and there you have on the General the indexing question.
The screenshot is in my language - not sure if it will help you, but still might give some light.
Interesting, I don't see this option here. kmail is on 14.0.7~pre28-0, mail folders are maildir format.
Right Click on the folder >> Properties >> “Act on new/unread mail in this folder”
I will guess that disables indexing as well?
Dunno, its been checked here since hectors grandpa was a puppy, no clue exactly what that means. When I have both eyes open at the same time I check the manual for an explanation. I've been up to make a trip to WVU/Ruby, they liked what they saw so a new aortic valve is scheduled to be installed on the 17th. That should put some giddyup back in my step. One of the hazards of outliving all your enemies. lol
Cheers, Gene Heskett
On Sunday 08 December 2019 04:06:14 David C. Rankin wrote:
On 12/07/2019 06:16 PM, Gene Heskett wrote:
I'm forced to agree. But if I have to do that, its likely I'll just jump ship to claws or even (spit) t-bird. This has been bugging me off and on for at least 5 years, and I've been mostly ignored, sent hundreds of crash reports all to no avail as far as solving the problem is concerned. Paypal has no clue who Tim is, so I've not been able to contribute, which bothers the hell outta me as a firm believer in TANSTAAFL. Not having paid my dues, I don't feel like I can demand.
Yes,
I've followed on and off your kmail woes. From what you describe this is a bug that should be fixed. kmail should not continually be putting a load on the system resorting indexes, etc.. There should be debugging that can be cranked up to cause TDE to spit out INFO level messages for kmail that may give a better picture of what is going on.
If the problem is that your mail store is too big for kmail to handle without thinking it needs to reindex -- that's still a bug and whether it is a Qt3 issue or kmail issue, both should be solveable today. (just off hand I can see if a limit is INT_MAX how a 20G mail store would be an issue), Regardless, whatever it triggering the reindexing needs to be identified.
Whatever was burning up the cores on your old box -- is still causing the same mischief on your new box -- it's just doing a whole lot more mischief a whole lot faster now....
That I think matches my swag on this, and it ought to be fixed. If anyone knows of a debug flag that would enable a window into this behaviour, I'm all ears, and can usually find and read logs.
Cheers, Gene Heskett
-
David C. Rankin -
deloptes -
Dr. Nikolaus Klepp -
E. Liddell -
Gene Heskett -
Michael -
William Morder via trinity-users