help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: using movemail directly in .emacs


From: lee
Subject: Re: using movemail directly in .emacs
Date: Thu, 05 Jun 2014 21:03:43 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> lee <lee@yun.yagibdah.de> writes:
>
>> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>>> In general though storing lots of emails in a file isn't really a
>>> problem.
>>> [...]
>>> Mbox files are very simple, it's hard to get writing to them
>>> wrong.
>>
>> That goes only as long as everything works as intended.  Have a power
>> failure or a yet-unnoticed disk failure, have your MUA crash due to some
>> bug or because the system kills it because it`s out of memory, have your
>> computer crash or freeze, have some issue with a network file system or
>> other things that don`t come to mind atm --- and your whole file with
>> all the mails may be gone.
>
> MUAs and MTAs have been using mbox files for a long time, they take
> precautions against this.  Rmail, for example, uses Emacs' default
> backup file system.  For each file MBOX there's a MBOX~ that can be used
> for recovery.

So you have like 1GB mbox and another 1GB mbox~ and copy that every time
you change a flag, like read, and perhaps you do that over the network
on a centralised storage or over a VPN connection using a modem.  In any
case, it`s horribly inefficient.

> [...]
> I've never lost any email because of this type of problem.  (I have lost
> it using Microsoft PST files though).

Those are particularly awful.  Microsoft doesn`t have any MUA which
could handle more than a handful of mails per day, if even that much.


> [...]
>>> I'm not saying that it's best to use mbox files, but the problems with
>>> them aren't large.  Large directory structures have other problems.
>>
>> Problems like?
>
> It asks a lot of the filesystem.

It merely asks of it what it was made for.

> Some filesystems can't handle long path and some can't handle certain
> characters in filenames.

Characters in file names aren`t a problem with maildir.

> Some behave quite slowly if a lot of directories are being checked.

Like which ones?  IIRC, extfs would slow down considerably with many
files in a directory, ext2 didn`t.  Using ancient file systems with mbox
doesn`t seem to be a good idea either, considering the increase of the
amounts of data they were designed to deal with and the amounts of data
we are dealing with nowadays.

> The minimum file size is quite large on many systems, so if you have
> lots of small emails then it wastes a lot of space.

I`ve investigated this problem quite a while ago with the actual mail
storage I have.  I found that most of the mails are between a little
over 2kB and below 4kB, so a minimum size of 4kB is fine.  If you use
anything larger for minimum size, you probably have rather special
requirements which may be suited better by a different file system.

> If I keep backup files that waste more space, but I can always delete
> a few of them if file length is an issue.  I can just copy a mbox file
> to a USB key, or download one from a website (such as the GNU mailing
> list archives).

You can always turn a maildir into a single file with tools like tar, or
copy it to an USB stick.  For archives, mbox can be a good thing to use.

> However, I don't think that Maildirs or MH are bad systems.  My mail
> point here is that mbox files aren't bad either.  The whole debate is
> about a few details that aren't really that important.

Well, I find reliability and efficiency important, and maildir and nnml
have advantages in that.


-- 
Knowledge is volatile and fluid.  Software is power.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]