On Fri, Nov 03, 2000 at 11:31:26AM -0600, Bruce Guenter wrote:
> On Fri, Nov 03, 2000 at 12:15:46PM -0500, Jan Harkes wrote:
> >  This happens to be the volume that
> > stores my incoming email in maildir format, and the combined size of all
> > the email (taken from cfs lv) is 41981 KB, so the average filesize is
> > relatively small, only about 9KB.
> 
> On a totally different topic, how well does this work?  That is, what
> are you using to deliver to the maildir, and how good is the
> performance?
> -- 
> Bruce Guenter <[email protected]>                       http://em.ca/~bruceg/

It works well for me, although there are a few gotcha's. I use procmail
+ maildir patches for delivery.

Coda does not and will not support cross-directory links. However, the
maildir specification states that a delivery should create a file in
tmp/, hardlink it to the same name in new/, and then remove the entry
from tmp/.

This is, I assume, to work around the fact that rename on NFS is not
guaranteed atomic and a file could get _lost_ during the rename operation.

So I've modified procmail and mutt, my email reader, pretty much like
this;

    int safe_rename(char *from, char *to)
    {
	struct stat_buf sb;
    
	err = link(from, to);
+	if (err == -1 && errno == EXDEV) {
+	    /* this may be Coda, try again using rename */
+	    err = rename(from, to);
+	}
	/* link failed */
	if (err == -1) return -1;
    
	err = stat(to, &sb);
	/* stat failed */
	if (err == -1) return -1;
    
	/* don't care when unlink fails */
	unlink(from);
	return 0;
    }
     
This patch was accepted and integrated by the mutt developers, but maybe
someone should at some point make similar patches for qmail and attempt
to convince DJB to update the maildir specification.

And there is a hard to fix Coda resolution bug which hits when a server
was down during maildelivery. When the new directory is resolved before
the tmp directory, the file doesn't yet exist on the second server as
the initial create and store haven't been resolved yet, and both
directories are marked as in-conflict. When the tmp dir is resolved
first everything is fine, but the mailcheckers are ofcourse only
checking the new directory.

Oh, and most maildir `compatible' mailcheckers seem to be really very
poorly implemented for checking maildirs. Most seem to be derived from
or sharing the checking code with MH delivery format mess around with
atime/mtime timestamps, they exhaustively stat all entries sometimes
even in both the cur and new subdirectories. This all is not needed for
maildir where a new-mail check should be nothing more than counting the
number of entries in the new directory, and as soon as it is more than 2
we can stop reading as we already know that new mail has arrived.

Jan