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@mascari.com