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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
