Hi I'm using KMail, KDE 3.2.3 and SuSE8.1. My mail folders are now starting to get very large. Some have more than 2,500 messages and I'm beginning to think that I should archive messages older than some date. However, is it necessary to do this? Does having so many messages slow the operation of KMail? I can't say I've noticed a slowing down but then the folders grow very slowly. If archiving is recommended then I'd still like to be able to access the archived folders/message with KMail in the easiest possible way. Is there are recommended way to do such archiving? Cheers John Satherley
On Friday 13 August 2004 11:05, John Satherley wrote:
Hi I'm using KMail, KDE 3.2.3 and SuSE8.1. My mail folders are now starting to get very large. Some have more than 2,500 messages and I'm beginning to think that I should archive messages older than some date. However, is it necessary to do this? Does having so many messages slow the operation of KMail? I can't say I've noticed a slowing down but then the folders grow very slowly. If archiving is recommended then I'd still like to be able to access the archived folders/message with KMail in the easiest possible way. Is there are recommended way to do such archiving? Cheers John Satherley
Hi John, I don't know if this slows down kmail but it sure fills up my home directory. There was an archive-and-compact script once, but on use I found that little practical. I do it the quick-and-dirty way: 1) when I find the Mail directory too big, I copy it to another partition, then tar-gz-it and burn it to a CD. 2) I then delete every mail that I don't feel to be important to keep (I keep some mails with passwords or serial numbers even if they have been archived In the (rare) case where I find out I'm missing a message, I rename Mail to Mail.old, un-tar-gz the old directory and copy it in the home directory, get the mail I was looking for, delete the directory and rename Mail.old to Mail. As I said, this is not very elegant but it's efficient, at least for me. Thierry -- "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former" - Albert Einstein
get very large. Some have more than 2,500 messages and I'm beginning to think that I should archive messages older than some date. However, is it necessary to do this? Does having so many messages slow the operation of KMail?
You would notice if they did. You can easily archive mail using various basic unix commands. Accessing archived mail with any modern mail client like kmail is essentially impossible, as none of them bothers to display mail from other than its own directory (GUI is nice, but some things are pretty braindead). grepmail is ideal for searching through archived mail if you archive in mbox format (which kmail or most/any new mail client can't handle properly). If you stick your mail into tar files you're out of luck searching through them without unpacking the lot first. Once you have found the mail from your archive which you want to look at, stuff them somehow into kmails Mail folder (default ~/Mail) *and* persuade kmail to have a look at it. So far it's been too dim to notice any new folders appearing, so most likely you'll have to quit and restart it. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
On Saturday 14 August 2004 06:02, Volker Kuhlmann wrote: [snip]>
Once you have found the mail from your archive which you want to look at, stuff them somehow into kmails Mail folder (default ~/Mail) *and* persuade kmail to have a look at it. So far it's been too dim to notice any new folders appearing, so most likely you'll have to quit and restart it.
Come on, Volker, restarting kmail shouldn't be such a problem! The alternative of constantly rescanning the ~/Mail/ folder content cannot be good, especially when we talk about many subfolders ... Regards, Matt
Volker
-- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Come on, Volker, restarting kmail shouldn't be such a problem!
:) Depends. I'm also wiping all its index files because kmail is unable to keep them matching reality, so startup takes time (as it also indexes absolutely everything, needed or not, on startup).
The alternative of constantly rescanning the ~/Mail/ folder content cannot be good, especially when we talk about many subfolders ...
That alternative is indeed bad. However, you'd only need to rescan a directory for either subdirectories or mbox files, you would only need to rescan the directory currently displayed in the index on the left (usually ~/Mail), and you would only need to rescan when there's activity in kmail, e.g. user changes folders. I make that a comparatively trivial amount of CPU time, certainly compared with the mindless activity to have to quit out of an app to make the app do its job (wasn't this a M$ solution?). Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
On Saturday 14 August 2004 07:17, Volker Kuhlmann wrote:
Come on, Volker, restarting kmail shouldn't be such a problem!
:) Depends. I'm also wiping all its index files because kmail is unable
to keep them matching reality, so startup takes time (as it also indexes absolutely everything, needed or not, on startup).
I see your point, yes, reindexing does take time, especially if you have lots of Mails. No matter if I reindex or not, the "order of arrival" sorting seems to be wrong quite often.
The alternative of constantly rescanning the ~/Mail/ folder content cannot be good, especially when we talk about many subfolders ...
That alternative is indeed bad. However, you'd only need to rescan a directory for either subdirectories or mbox files, you would only need to rescan the directory currently displayed in the index on the left (usually ~/Mail), and you would only need to rescan when there's activity in kmail, e.g. user changes folders. I make that a comparatively trivial amount of CPU time, certainly compared with the mindless activity to have to quit out of an app to make the app do its job (wasn't this a M$ solution?).
I see your point. But think about this: When do you want the app to be quickly, if not instantly, doing what you want? For me it is when I change the folder, I do not want to wait a second, I want it instantly changed to the new one, and not worry if it got my click or not. Now if I have a desktop with fast hdds it will be almost instantly, the rescanning will probably not get noticed. But if I'm on my notebook and the hdds have to restart because I change the mail folder, and whatever cache does not help because it needs to rescan, just in case of a change, then that's annoying, too. I rather accept a longer start up time. And - how often do I push another folder under kmails butt? Last time it was almost a year ago... Have fun! Matt
Volker
-- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
No matter if I reindex or not, the "order of arrival" sorting seems to be wrong quite often.
Yes. It's ***ed. Kmail doesn't have any idea about what an arrival time is. It even copies the date from the Date: header into the values it uses for arrival time (the From_ line for mbox files), overwriting the arrival time which is there already. That's bad! Using the top-most Received: might be acceptable. Displaying "mailbox order" would be nice too. A standard feature with old-guard clients.
I see your point. But think about this: When do you want the app to be quickly, if not instantly, doing what you want?
Always. Pity that what I want the app to do isn't what the kmail programmers want me to want to do... I have all mailing list msgs delivered into a subdirectory tree to which kmail doesn't have access, because I don't want it to screw all my msgs up (e.g. received time, and it's likely to destroy files because it can't share access with procmail). This keeps the rescan time down too. Actually there's a trick, though it's a tad annoying: touch the file more than 10 seconds after kmail last displayed it, and it's rescan it when you next visit it. It'll never find new folders though, you'll have to nuke it for that.
For me it is when I change the folder, I do not want to wait a second, I want it instantly changed to the new one,
Fair enough. But our two uses and requirements are not mutually exclusive. However, its narrow-minded view of mail files prevent you from displaying archived mail on CD or anywhere else. Pooping index files all over the show may be very performance boosting in some cases, but is disastreous in others.
And - how often do I push another folder under kmails butt? Last time it was almost a year ago...
Each time I want to look at archived mail, or the results of a grepmail run. Thank goodness there are still dependable workhorses around which get the job done quickly (I use mutt) as opposed to convolutedly or not at all, although moving forward a bit in time would be nice. (Something like mutt is still a must when working remotely.) Hey, it'd be trivial to put another entry called "rescan now" in the little menu which pops up on right-click. I suggested that, uhm, a year ago maybe. The developer(s) agreed it would be a good idea. That was a year ago too. kmail is just about perfect for sending mail, but for receiving mail and working with on-disk or archived mail it's seriously deficient.
Have fun!
Sure do! :) Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Hi to all you replied to my initial question. Thanks for your helpful comments. Clearly KMail is not suited to dealing directly with archived mail and archiving using other methods seems to be possible but messy. I wonder then whether there are other mail clients better suited to handling live folders as well as archived material? I've been using KMail for several years and in that time I have not experienced any problems with it and would be loathed to leave it but if there is a better one then I'd certainly give it a try particularly if my current mail can be transferred without problem. Cheers John On Sunday 15 August 2004 07:32, Volker Kuhlmann wrote:
No matter if I reindex or not, the "order of arrival" sorting seems to be wrong quite often.
Yes. It's ***ed. Kmail doesn't have any idea about what an arrival time is. It even copies the date from the Date: header into the values it uses for arrival time (the From_ line for mbox files), overwriting the arrival time which is there already. That's bad! Using the top-most Received: might be acceptable.
Displaying "mailbox order" would be nice too. A standard feature with old-guard clients.
I see your point. But think about this: When do you want the app to be quickly, if not instantly, doing what you want?
Always. Pity that what I want the app to do isn't what the kmail programmers want me to want to do...
I have all mailing list msgs delivered into a subdirectory tree to which kmail doesn't have access, because I don't want it to screw all my msgs up (e.g. received time, and it's likely to destroy files because it can't share access with procmail). This keeps the rescan time down too.
Actually there's a trick, though it's a tad annoying: touch the file more than 10 seconds after kmail last displayed it, and it's rescan it when you next visit it. It'll never find new folders though, you'll have to nuke it for that.
For me it is when I change the folder, I do not want to wait a second, I want it instantly changed to the new one,
Fair enough. But our two uses and requirements are not mutually exclusive. However, its narrow-minded view of mail files prevent you from displaying archived mail on CD or anywhere else. Pooping index files all over the show may be very performance boosting in some cases, but is disastreous in others.
And - how often do I push another folder under kmails butt? Last time it was almost a year ago...
Each time I want to look at archived mail, or the results of a grepmail run. Thank goodness there are still dependable workhorses around which get the job done quickly (I use mutt) as opposed to convolutedly or not at all, although moving forward a bit in time would be nice. (Something like mutt is still a must when working remotely.)
Hey, it'd be trivial to put another entry called "rescan now" in the little menu which pops up on right-click. I suggested that, uhm, a year ago maybe. The developer(s) agreed it would be a good idea. That was a year ago too.
kmail is just about perfect for sending mail, but for receiving mail and working with on-disk or archived mail it's seriously deficient.
Have fun!
Sure do! :)
Volker
-- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Clearly KMail is not suited to dealing directly with archived mail and archiving using other methods seems to be possible but messy. I wonder then whether there are other mail clients better suited to handling live folders as well as archived material?
I'd like to know too! It seemed to me that all the modern clients, which tend to be GUI clients, are programmed with the same frame of mind, namely with the assumption that all your mail is stored in some humangous imap repository or else the same directory, and is in some kind of directory format (i.e. one mail per file). A kmail developer told me outright that kmail expects to be the only(!!!) application accessing the directory where the mail is stored in (wow that's bad). I fear all other modern/new/GUI clients are the same. A more satisfactory solution would be nice indeed. So far it's mutt. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Hey Volker,
A kmail developer told me outright that kmail expects to be the only(!!!) application accessing the directory where the mail is stored in (wow that's bad). I fear all other modern/new/GUI clients are the same. A more satisfactory solution would be nice indeed. So far it's mutt.
... that's exactly my experience. All or most email client software has some sort of import filter to import MS Outlook, Mozilla, Netscape, Eudora or other well known mailboxes. But _none_ of them has an export function that produces some general format. :-( -- cul8er Paul paul.foerster@gmx.net
*** Reply to message from Volker Kuhlmann
grepmail is ideal for searching through archived mail if you archive in mbox format (which kmail or most/any new mail client can't handle properly).
question here? Is Kmail not saving it's files as plain text? So in theory it could be read by any text reader ??? I 'm not trying to smart off here, I don't use it because my own mailer ( which has it's own "teathing" problems <sigh> ) does save all it's files in plain text, and in the event that it won't install somewhere I *can* look into any files I need w/ a text editor. ( It isn't ideal but at least I can see adddresses and messages etc.) IF kmial saves it's messages in plain text they could be read by kate or ??? no? -- j -- nemo me impune lacessit
grepmail is ideal for searching through archived mail if you archive in mbox format (which kmail or most/any new mail client can't handle properly).
question here? Is Kmail not saving it's files as plain text?
Yes it is.
So in theory it could be read by any text reader ???
Yes. What I'm unsure about is how grepmail handles maildirs because I don't use them. Just try it out. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
* Volker Kuhlmann
What I'm unsure about is how grepmail handles maildirs because I don't use them. Just try it out.
pod2text grepmail grepmail.txt yelds: mailbox Mailboxes must be traditional, UNIX "/bin/mail" mailbox format. The mailboxes may be compressed by gzip, tzip, or bzip2, in which case gunzip, tzip, or bzip2 must be installed on the system. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos
participants (7)
-
jfweber＠bellsouth.net -
John Satherley -
Matt T. -
Patrick Shanahan -
Paul Foerster -
Thierry de Coulon -
Volker Kuhlmann