(Illustration by Gaich Muramatsu)
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 <bruceg@em.ca> 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. JanReceived on 2000-11-03 13:31:47