The problem which John is worried about is the data of the containing
directory, which fsync() does not concern itself with. And it can't,
really. When you call fsync(), you pass it a file descriptor; the
kernel has no way of knowing which one of potentially many containing
directories should also be flushed out to disk.
John's solution is to set the ext2 'S' attribute on the directory, and
this does work.
> crashes before that buffer gets flushed, the message gets lost. There
> is no way the application can commit the directory change short of
> calling sync().
Actually, there is, but it's not portable. If you open the directory
using open, and then call fsync on the resulting file descriptor, you
will forcibly commit the directory change. This is *not* guaranteed to
work on all POSIX systems, and indeed it may not work on many. But it
will work under Linux.
Still, it probably wouldn't be a bad idea for a paranoid application to
try opening the directory, and if the open succeeds, keep a handle on
that directory and call fsync() on that file descriptor after any
critical rename() calls. I suspect it shouldn't do any harm on most
Unix platforms.
- Ted