Re: Win32 rename()/unlink() questions

Bruce Momjian wrote:
> I am working with several groups getting the Win32 port ready for 7.4
> and I have a few questions:
>
> What is the standard workaround for the fact that rename() isn't atomic
> on Win32? Do we need to create our own locking around the
> reading/writing of files that are normally updated in place using
> rename()?

Visual C++ comes with the source to Microsoft's C library:

rename() calls MoveFile() which will error if:

1. The target file exists
2. The source file is in use

MoveFileEx() (not available on 95/98) can overwrite the target
file if it exists. The Apache APR portability library uses
MoveFileEx() to rename files if under NT/XP/2K vs. a sequence of :

1. CreateFile() to test for target file existence
2. DeleteFile() to remove the target file
3. MoveFile() to rename the old file to new

under Windows 95/98. Of course, some other process could create
the target file between 2 and 3, so their rename() would just
error out in that situation. I haven't tested it, but I recall
reading somewhere that MoveFileEx() has the ability to rename an
opened file. I'm 99% sure MoveFile() will fail if the source
file is open.

>
> Second, when you unlink() a file on Win32, do applications continue
> accessing the old file contents if they had the file open before the
> unlink?
>

unlink() just calls DeleteFile() which will error if:

1. The target file is in use

CreateFile() has the option:

FILE_FLAG_DELETE_ON_CLOSE

which might be able to be used to simulate traditional unlink()
behavior.

Hope that helps,

Mike Mascari
mascarm(at)mascari(dot)com