Randall wrote regarding 'Re: [SLE] KMail question' on Fri, Aug 13 at 11:23:
Danny,
On Friday 13 August 2004 08:56, Danny Sauer wrote:
Randall wrote regarding 'Re: [SLE] KMail question' on Thu, Aug 12 at 16:46:
...
Perhaps you should consider storing those mbox files gzipped, too. They're text files, and compress very well. Waste is waste, you know? :)
I don't see this option in KMail's options dialogs. How does one do this? Under Windows, I always applied system-level compression to the files that stored my mailbox files (Eudora always uses mbox format, by the way). Actually, I used compression for my archived mail, but kept active mailboxes (those still receiving new mail) uncompressed.
I had something like squashfs in mind, but it appears to be read-only. I was sure there was a dynamic compression option at the filesystem level in one of the filesystems, but it eludes me for now. Maybe one of those that support dynamic encryption? Maybe I was thinking of the planned ext4... Eh, that'd require a seperate partition anyway. Is read-write NTFS support stable yet? :)
New mail is always appended to the end of the file. No power failure is going to disrupt a single sector write (modern "Winchester" drives [...]
What happens when you delete a message? That's right, the portion of the file after that deleted message has to be rewritten. When you pop your mail, and the pop server's deleting the first few messages, what [...]
You seem to be confusing local mail storage by the client (KMail) and mail storage in mail drop files or on servers. The latter is not what we're discussing. SMTP, POP, IMAP, mail drop files etc. are all irrelevant here.
I was discussing Maildir for general mail storage, typically on a server. I'd just as soon have my client store messages in RAM, personally, since my workstations typically have enough RAM to do so. Perhaps this is why we're not seeing eye-to-eye - different topics of dission. :)
The deleted message are simply abandoned. The index no longer refers to them. When the mailbox file is compacted (I compact when exiting), that abandoned space is recovered. I also "hope" that KMail's file compaction is implemented intelligently, i.e., so as to minimize the likelihood of data loss in the unlikely event that some sort of hardware or software failure occurs during compcation.
Again, on a mail client, an mbox file would probably be fine, since there can be a resident index, only one program accessing it, etc. I don't use kmail, I use mutt on the same file that messages get delivered to and the same spool that a couple of other programs check periodically via IMAP. So, from my client view, I prefer maildir. If I was using Kmail - which won't happen due to the major problems it's caused me - mbox would be just fine if that's what it wanted to do. Anyway, I figured that we'd drifted away from just kmail and back to maildir v/s mbox in general...
And please stop winking at me, OK?
Preference noted. :p --Danny, using emoticons to compensate for lack of inflection 'n body language