Len Budney <[EMAIL PROTECTED]> writes:
> Journalling is absolutely orthogonal to the reliability issue. The
> reliability issue is: What are the semantics of fsync(), link() and
> rename()? If they return after the requested operation completes to disk,
> we can guarantee reliability. If not, we can't.
Rename() is _supposed_ to guarantee that the target file is intact upon
completion, although IMHO one should still fsync() the source file itself
before rename()ing it to its destination. The rename() call was
originally meant more for operations like installing a new /bin/sh
safely; you want guarantees that another user won't get "/bin/sh: not
found" while you're working, and that an untimely crash won't leave you
without a valid /bin/sh. Things are less critical in applications where
the target does not already exist, but IMHO a rename() that doesn't sync
FS metadata before returning is broken.
In this connection, I should mention http://www.qef.com/ftp/rename.ps,
the classic rename() paper that describes real-world grief in a lot of
the early implementations. A lot may have changed since then, but I
wouldn't count on sudden industry-wide clue acquisition.
--
Anthony DeBoer <[EMAIL PROTECTED]>
