rename() (was Re: ext3-2.4-0.9.4)

[Anthony DeBoer]

Patrick J. LoPresti <[e-mail]> wrote:
>The MTAs do this:
>
>    Open temp file
>    Write to temp file
>    fsync() temp file
>    rename() temp file into mail spool
>    indicate success to remote MTA

Don't forget the unlink() temp file just before or after that last step.

>As long as rename() does not return until the metadata are committed,
>this should be a reliable delivery mechanism.  ...

As I understand it, rename() was originally invented for tasks like
installing a new /bin/sh with guarantees that another process running
at the same time would not fail to find a shell, and that if the system
fell over during the install you'd still have a shell on reboot.

See http://www.qef.com/ftp/rename.ps for an interesting history from
someone who was there at the time.  It's undated, but probably a decade
old.

It's my considered opinion that rename() _should_ fsync the target
directory before returning, and between that and the fsync() call on
the file itself (an install program should do the same call sequence as
above) you get the guarantee that the file is intact before you unlink
the temp version and return success.  OTOH, link() and unlink() are not
in the business of providing guarantees like that, and should not sync.

-- 
Anthony de Boer, curator, Anthony's Home for Aged Computing Machinery
<[e-mail]>