Atomically replace a file; How?

[a f f l e s 2@worldnet.att.net Ron Ruble]

lbu...@pobox.com wrote in message <8bo6ec$ecj$1...@nnrp1.deja.com>...
>Hello!
>I'm porting some daemons from UNIX to Windows NT 4.0. They have some
>stringent reliability constraints, and I don't know how to meet those
>constraints under Windows.
>Can somebody answer the following questions? If the questions themselves
>are off-base for NT-world, can you make my mind right?
>1. How do I replace a file, _atomically_? The service keeps some config
>data in a text file, and another service sometimes modifies the
>file. It is imperative that the file never vanish under any
>circumstances. Under UNIX, rename() does exactly the right thing;
>under Win32, rename() fails and returns -1 when the destination
>file exists.

I have no specific information on the atomicity of rename
operations, however, I would recommend checking into
the MoveFileEx() API call, which I think may meet your needs.

From the MSDN documentation:
........
dwFlags
[in] Specifies how to move the file. This parameter can
be one or more of the following values.
........
MOVEFILE_WRITE_THROUGH The function does
not return until the file has actually been moved on the disk.
Setting this flag guarantees that a move performed as
a copy and delete operation is flushed to disk before the
function returns. The flush occurs at the end of the copy
operation.

>2. Can I flush a file to disk, synchronously? Can I rename it
>synchronously? One way to queue a request is to flush it to a file,
>and then rename() the file into the destination directory. This
>gives a 100% reliability guarantee, _IF_ the action is synchronous.
>If the call can return success, before the action is taken, then
>a server crash will result in lost requests.

Check into the WriteFile API function. Again, I have no
specific information on it's atomicity.

Bear in mind, the C standard library under Win32 is not
a slightly abstracted version of how the underlying OS
functions, as it is in Unix; it is an abstract layer implemented
largely outside of the native OS operations.

Microsoft also tends to model C standard library function
'implementation defined behavior' around the expectations
of former DOS programmers, rather than Unix behavior.

The behavior of the rename function is an example
of this; perfectly acceptable according to the ANSI/ISO
standard, and at odds with the expectations of Unix
programmers.

By contrast, the Win32 API is a very close approximation
of how Windows is internally designed.

Also, since you need to coordinate 2 or more processes,
check into Windows synchronization objects. Mutexes,
Semaphores, etc., are all built into Windows.