On Fri, 2003-06-06 at 15:23, Anne Wilson wrote: > On Friday 06 Jun 2003 8:14 pm, Steffen Barszus wrote: > > Am Freitag, 6. Juni 2003 21:04 schrieb Anne Wilson: > > > My dally with evo made me aware that I had a mixture of maildir > > > and mbox for my mail - obviously not ideal - so I set out to > > > convert to one. I chose mbox, because it is transparent. I know > > > that if I could not use kmail I can open one of my archive > > > folders in a text editor and do a search to find anything I need. > > > I like the comfort factor that gives me. > > > > > > I have heard it said, though, that mbox if bad, and maildir is > > > good. Why? Are there any overriding reasons for going that way? > > > > > > Anne > > > > Hmm at least your argument for mbox isn't really valid. Maildir is > > too plain text and directories. > > But searching 10,000 archived messages individually for a particular > phrase is not a good idea. One large file with the messages > concatenated is much easier, if slow. > > > Don't know which one is better. > > Maybe this is interesting for you (not really;)) > > > > http://www.courier-mta.org/mbox-vs-maildir/#theend > > > Having read that, I think it's a matter of 'you pays your money and > you takes your choice' - which is fine by me. There doesn't seem to > be any strong reason to override personal preference. > > Thanks, Steffen > > Anne >
Mbox is considered an inferior format because in the past it has resulted in the loss of much mail. Potentially if the file borks you lose the whole load. Maildir, on the other hand (as others have already stated) stores the text in files which all have naming conventions that are determined by standardized procedures stored in an RFC somewhere. The advantage to this is that if there is damage to any of the files, you might lose a few emails but you won't nuke the whole storehouse. The reasons the different directories exist (cur, tmp, and new) is a further refinement of the safety process built into the maildir procedures, in that when mail is being received, it is granted a temporary position in the "tmp" spot and then moved to the "new" directory after it is safely written. This lowers the possibility that inodes in any other vital directories (such as where the main email storage is) won't get borked during the file creation process if something goes wrong. Only after the email has been totally written and created (i.e. stabilized) is it moved to it's final position in "new". The "new" directory loses it's email as soon as a MUA program (such as Evolution) reads the mail. Evo knows to look in "new" for new email, and as soon as it does the mail is planted in cur for categorization or retrieval. One thing that kind of bothers me is that Dan Bernstein, the author of Qmail, happens to be the guy that came up with the entire Maildir scheme, and although his concept has been widely used, few people know who's genius it was that originated it. In other words it was originally a qmail function and has since been ripped for use in other MTA programs (because of it's popularity), offtimes without the recognition that Dan Bernstein (DJB) designed it. What you have to realize is that with mbox, every time you get email, every single message is basically an append to one single large file, the file that contains your email. That's a lot of chances for something to go wrong. Sooner or later the law of averages is going to catch up with somebody. (and it already has) One example I can think of is if you are receiving email while the power goes out. An mbox being written to is in an indeterminate state. --LX -- 같같같같같같같같같같같같같같같같같같같같같같같같 Kernel 2.4.21-0.13mdk Linux Mandrake 9.1 Enlightenment-0.16.5-12mdk Evolution 1.2.4-1.1mdk Linux User #268899 http://counter.li.org/ 같같같같같같같같같같같같같같같같같같같같같같같같
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
