To avoid huge directories, we "archive" mails. Archiving acutally moves mails, say, from a whole month, into a mbox.Month directory. After months using this approach, I´ve seen no problem regarding slow downs on big directories.
The need for OEXCL can be avoided by storing each mail in a directory named with a random number. In our case, the dir contains a "text" file that can be open in acme/omero to read the mail, and one file (or dir, if it´s a mail) per attach. Only the real system mbox has to be OEXCL, to prevent races between incomming mail and mail2fs processes. httlp If there's interest in trying this, I can move the mail2fs cleanup to a higher place in my todo list. hth On 10/30/05, Paul Lalonde <[EMAIL PROTECTED]> wrote: > I used to keep all my mail this way using MH; it worked well up to > the point where directories got so full that directory operations > were taking too long (I remember a nasty n^2 sort in the early days > of linux). If Plan9's file handling is up to it, I'm in favour of > this approach. Just remember that it has to work well with 10's of > thousands of emails in a directory - search is making organization > obsolete. Heck, some of us didn't manage organization before search > made it obsolete.
