I had reason to be reminded recently of a crash we had early this year
on a machine still running SunOS 4.1.3 [irrelevant] and smail [relevant].
Without going into details, suffice it to say that it had to be rebooted
without sync'ing after being in a very knotted state, required manual
fsck'ing on the /var partition, and ended up with several dozen files
in /var/lost+found most of which were mail-related.
Because I could easily identify which ones belonged in smail's /input
directory, I was able to just move them back (assigning "impossible"
message-ids arbitrarily), while the /msglog ones I just discarded. This
may have meant a few double deliveries, as smail used to use the msglog
files for recording deliveries already done.
Suppose we had been running exim rather than smail. The input/*-H files
would be easily identified, and maybe even the input/*-D ones. But could
one ever match up one with the other? I suppose one could invent -D files
containing "Unfortunately, we lost the text of this message. Ask the sender
for another copy...".
Of course, exim's scheme of double /input files has a lot going for it
in other respects. Is this sort of repair job just something one has to
give up as a consequence? Has anyone had any interesting disk crashes while
running exim, and what were they able to do?
Chris Thompson Cambridge University Computing Service,
Email: cet1@??? New Museums Site, Cambridge CB2 3QG,
Phone: +44 1223 334715 United Kingdom.
