Carlos E. R. wrote:
On Friday, 2009-02-13 at 20:09 +0100, Sandy Drobic wrote:
Yes, so do I, fetchmail, postfix, procmail. But that doesn't mean I have to use maildir. I will not while it doesn't become a standard for all programs. I have read some very strong things agains maildir from some developpers...
Care to tell what kind of problems in what context were caused by maildir?
Just ask dev Mark Crispin what he thinks about maildir... in the context of MUAs, specially, not servers. I have links to the alpine-alpha mail list, where he has been quite explicit, but they require password.
For example: inode waste, in the count of millions. Slow text search, unless you use some database indexing, like beagle. It does not really support concurrency, like one client reading one email and another different client erasing that same email. That there is no standard, and each client or server does its own interpretation. Courier, for instance, uses something like maildir, but not actually maildir.
Granted, it does use more space to store mails in separate files than in one big inbox, this will also slow down search operations since it takes a lot more I/O to scan lots of small files compared to one big file. Though I challenge you to give me one real life example where one user/program is reading a mail and another one is deleting the same mail without it being a misconfiguration. (^-^) Especially the issue of concurrency is exactly why maildir is superior to mbox. Try to have ten applications submit mails to the mailbox at the same time. With mbox you will have to serialize it and lock/unlock the mbox files. It has a severe performance drop and is known to cause lots of problems when separate applications are supposed to access mails from the mbox file. You will find a lot of woe reports in the postfix-users mailing list, where users reported performance problems, when the files got big and lots of mails hat to be delivered to the mbox files. The result was delayed delivery due to frequent timeouts on delivery when the new mail could not be added to the mbox file in time. Another problem that often occured was mbox files on nfs storage. The locking was often problematic. The issue with an imap server not using maildir you mentioned is probably Cyrus imap, not Courier. Courier does use maildir while Cyrus uses its own proprietary storage format, even if the mails are stored in single files. At this point I haven't even started on the problem of acls on shared mailboxes and how they are supposed to work on a single big file.
I am, of course, interested in the client side. What an imap server uses internally, does not matter. And the problem is that not all mail client use the same format of maildir folders, if they use any at all. The two clients I use most, ie, Alpine and Thunderbird, do not support maildir.
True, though I consider is little loss. It is easier and more in the spirit of linux to use programs that do their job well and not to have a multipurpose do-it-all program with many features and an equal collection of bugs and incompatibilities. So I someone uses email intensively it does make sense to let an imap server handle mailstorage and simply use a client that works via imap. That way you can have your choice of clients without having to worry about mailstorage format or migrating all your stored mails to another format just to test a new client. It's fine to use mbox for smaller and few mailboxes but it will simply not scale. By the way, does anyone know if the problematic setup with the 2 GB mbox files was a 64bit system? I wonder if it was a 32bit limitation of the program and if it could be avoided on a 64 bit system. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org