Bruce Momjian wrote:
> Bruce Momjian wrote:
>>>
>>>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.
>>
>>No, that flag isn't going to help us. I wonder what MoveFileEx does if
>>the target file exists _and_ is open by another user? I don't see any
>>loop in that Win32 rename() routine, and I looked at the Unix version of
>>apr_file_rename and its just a straight rename() call.
>
>
> This says that if the target is in use, it is overwritten:
>
> http://support.microsoft.com/default.aspx?scid=KB;EN-US;q140570&
I read the article and did not come away with that conclusion.
The article describes using the MOVEFILE_DELAY_UNTIL_REBOOT
flag, which was created for the express purpose of allowing a
SETUP.EXE to remove itself, or rather tell Windows to remove it
on the next reboot. Also, if you want the Win32 port to run in
95/98/ME, you can't rely on MoveFileEx(), you have to use
MoveFile().
I will do some testing with concurrency and let you know. But
don't get your hopes up. This is one of the many advantages that
TABLESPACEs have when more than one relation is stored in a
single DATAFILE. There was Oracle for MS-DOS, after all..
Mike Mascari
mascarm@mascari.com