Re: qmail corrections

> It seems to me that someone has rattled your chain !

Say an exim system panics and reboots. Will any mail be lost or damaged?

Say an exim system suffers a power outage---the disk doesn't even get
synced. Will any mail be lost or damaged?

These events will happen. They will happen frequently. What are you
going to say to a user after exim destroys an important piece of mail
that it accepted responsibility for delivering?

> Can you help us answer that question by indicating the sort of steps you mean,
> by explaining what qmail does ?

There's an extensive literature on crashproof databases. The idea is
that you start from certain atomic operations---for a typical UNIX
filesystem, for example, link() is atomic---and you build higher-level
atomic operations.

Basic example: replacing the contents of a file. If you simply open the
file O_WRONLY | O_TRUNC and write the new contents, what happens if the
system goes down in the middle? You get a truncated file. In fact,
appending isn't atomic, so you could end up with a truncated file
followed by some empty space. In fact, there's no guarantee that disk
blocks are written out in the order you create them, so the file could
end up looking very strange. In contrast, if you open a temporary file,
write the data to that file, fsync() the file, and rename() it on top of
the old file, the BSD FFS will guarantee that the whole file is replaced
atomically. Of course, you also need procedures to look for and clean up
extra temporary files created by crashes, and you need to guarantee that
the procedures won't delete a file that's simply being created slowly.

See INTERNALS in the qmail package for an explanation of qmail's queue
structure.

> SO: if you've found some bugs, please let us know so that we can fix them.

Of course. I have no intention of quietly criticizing exim behind your
back. If I see any problems with exim, I'll let you know.

---Dan