Date:        Fri, 16 Jun 2000 09:30:06 -0400
    From:        Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
    Message-ID:  <200006161330.NAA21374@orchard.arlington.ma.us>

  | What recent versions of sendmail do is:
  | 
  | 	write message to file
  | 	fsync file
  | 	rename file (to indicate that the file is a complete message)
  | 	fsync file
  | 
  | If you add the second fsync to force the rename out to disk, you
  | should be all set..

Is that really guaranteed?   rename() is an operation on the directory,
not the file - the only operation it performs on the file (the inode
of the file) is to update the inode changed time (and that really only
for historical reasons).   I can't think of any particular reason that a
filesystem which is attempting to maximise effeciency, while retaining
internal consistency, would care much when the inode change time update
was done with respect to the directory changes that are going on.  If
the inode is flushed before the rename finishes (before the updated
directory is flushed) then the problem would still be there.

If the rename was being done by a link/unlink combination, which was
actually altering the link count in the inode, then I'd tend to trust
it more (as the inode count can't be decremented after the unlink
until after the directory has actually been updated).

That being said, I'd be a little surprised if Kirk hadn't considered
the needs of sendmail in the design of all of this...

kre