7 Dec
2019
7 Dec
'19
11 a.m.
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>
7 Dec
7 Dec
3:05 p.m.
New subject: [trinity-users] my KMail problems, continued
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-cr…
https://www.shellhacks.com/fake-file-access-modify-change-timestamps-linux/
https://www.thegeekstuff.com/2012/11/linux-touch-command/
5:02 p.m.
New subject: [BULK] Re: [trinity-users] my KMail problems, continued
On Saturday 07 December 2019 10:05:31 Michael wrote:
On Saturday 07 December 2019 05:00:56 am Gene Heskett
wrote:
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.
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.
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(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-users-help(a)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
--
"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>
11:11 p.m.
New subject: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
On Sat, 7 Dec 2019 12:02:31 -0500
Gene Heskett <gheskett(a)shentel.net> wrote:
On Saturday 07 December 2019 10:05:31 Michael wrote:
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
“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?
8 Dec
8 Dec
12:16 a.m.
New subject: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
On Saturday 07 December 2019 18:11:26 E. Liddell wrote:
On Sat, 7 Dec 2019 12:02:31 -0500
Gene Heskett <gheskett(a)shentel.net> 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.
Wrong list, but can claws handle a 20+ gig corpus of email stretching
back 20 years?
On Saturday 07 December 2019 10:05:31 Michael
wrote:
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.
“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? E. Liddell
Thanks, E. Lidell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-users-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-users-help(a)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
--
"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>
2:05 a.m.
New subject: [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
On Saturday 07 December 2019 16:16:30 Gene Heskett wrote:
On Saturday 07 December 2019 18:11:26 E. Liddell
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?
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 Sat, 7 Dec 2019 12:02:31 -0500
Gene Heskett <gheskett(a)shentel.net> 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.
Wrong list, but can claws handle a 20+ gig corpus of email stretching
back 20 years?
On Saturday 07 December 2019 10:05:31 Michael
wrote:
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. “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? E. Liddell
Thanks, E. Lidell
2:42 a.m.
New subject: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
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:
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.
On Saturday 07 December 2019 18:11:26 E. Liddell
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?
On Sat, 7 Dec 2019 12:02:31 -0500
Gene Heskett <gheskett(a)shentel.net> 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.
Wrong list, but can claws handle a 20+ gig corpus of email
stretching back 20 years?
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
Thanks, E. Lidell 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(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-users-help(a)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
--
"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>
2:54 a.m.
New subject: [trinity-users] my KMail problems, continued
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:
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.
On Saturday 07 December 2019 16:16:30 Gene
Heskett wrote:
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.
On Saturday 07 December 2019 18:11:26 E. Liddell
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? On Sat, 7 Dec 2019 12:02:31 -0500
Gene Heskett <gheskett(a)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 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.
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
11:51 a.m.
New subject: [BULK] Re: [trinity-users] my KMail problems, continued
On Saturday 07 December 2019 21:54:46 William Morder via trinity-users
wrote:
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.
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.
Take care Bill.
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>
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. 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.
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
7:34 p.m.
New subject: [BULK] Re: [trinity-users] my KMail problems, continued
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:
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.
On Saturday 07 December 2019 21:05:09 William
Morder via
trinity-users
wrote:
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.
On Saturday 07 December 2019 16:16:30 Gene
Heskett wrote:
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.
On Saturday 07 December 2019 18:11:26 E. Liddell
wrote:
> On Sat, 7 Dec 2019 12:02:31 -0500
>
> Gene Heskett <gheskett(a)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.
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.
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
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-users-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-users-help(a)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
--
"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>
8:04 p.m.
New subject: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
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
--
"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>
9:34 a.m.
New subject: [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)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
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
9:06 a.m.
New subject: [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
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, J.D.,P.E.
9:16 a.m.
New subject: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
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
12:46 p.m.
New subject: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
On Sunday 08 December 2019 04:16:10 deloptes wrote:
David C. Rankin wrote:
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
--
"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>
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
7:23 p.m.
New subject: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
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
10 Dec
10 Dec
1:45 a.m.
New subject: [trinity-users] Re: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
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.
--
David C. Rankin, J.D.,P.E.
3:18 a.m.
New subject: [BULK] Re: [trinity-users] Re: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
On Monday 09 December 2019 20:45:33 David C. Rankin wrote:
On 12/08/2019 06:46 AM, 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.
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>
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.
7:47 p.m.
New subject: [BULK] Re: [trinity-users] Re: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
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.
10:07 p.m.
New subject: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
On Tuesday 10 December 2019 14:47:12 deloptes wrote:
Gene Heskett wrote:
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.
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?
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(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-users-help(a)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
--
"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>
10:33 p.m.
New subject: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
Gene Heskett wrote:
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
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. 
11:33 p.m.
New subject: [BULK] [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
On Tuesday 10 December 2019 17:33:29 deloptes wrote:
Gene Heskett wrote:
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
--
"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>
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.
11 Dec
11 Dec
8:53 a.m.
New subject: [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
Anno domini 2019 Tue, 10 Dec 23:33:29 +0100
deloptes scripsit:
Gene Heskett wrote:
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
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
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.
2:09 p.m.
New subject: [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
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:
Right Click on the folder >> Properties >> “Act on new/unread mail in this
folder”
I will guess that disables indexing as well?
Gene Heskett wrote:
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. 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?
3:36 p.m.
New subject: [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
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:
Hm, I always wondered what that option actually does.
Nik
Anno domini 2019 Tue, 10 Dec 23:33:29 +0100
deloptes scripsit:
Right Click on the folder >> Properties >> “Act on new/unread mail in this
folder”
I will guess that disables indexing as well? Gene Heskett wrote:
Interesting, I don't see this option here. kmail is on 14.0.7~pre28-0, mail
folders are maildir format. > 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)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
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
8:05 p.m.
New subject: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
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.
12 Dec
12 Dec
12:27 a.m.
New subject: [BULK] Re: [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
On Wednesday 11 December 2019 09:09:54 Michael wrote:
On Wednesday 11 December 2019 02:53:32 am Dr. Nikolaus
Klepp wrote:
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
--
"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>
Anno domini 2019 Tue, 10 Dec 23:33:29 +0100
deloptes scripsit:
Right Click on the folder >> Properties >> “Act on new/unread mail in
this folder”
I will guess that disables indexing as well?
Gene Heskett wrote:
Interesting, I don't see this option here. kmail is on
14.0.7~pre28-0, mail folders are maildir format. > 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.
8 Dec
8 Dec
12:01 p.m.
New subject: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued
On Sunday 08 December 2019 04:06:14 David C. Rankin wrote:
On 12/07/2019 06:16 PM, Gene Heskett wrote:
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
--
"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>
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....
1598
days inactive
1603
days old
27 comments
7 participants
participants (7)
-
David C. Rankin -
deloptes -
Dr. Nikolaus Klepp -
E. Liddell -
Gene Heskett -
Michael -
William Morder via trinity-users