Mike Mascari wrote:
> > foo contains: "FOO"
> > bar contains: "BAR"
> >
> > 1. Process 1 opens "foo"
> > 2. Process 2 opens "foo"
> > 3. Process 1 calls MoveFile("foo", "foo2");
> > 4. Process 3 opens "foo" <- Successful?
> > 5. Process 1 calls MoveFile("bar", "foo");
> > 6. Process 4 opens "foo" <- Successful?
> > 7. Process 1 calls DeleteFile("foo2");
> > 8. Process 1, 2, 3, 4 all read from their respective handles.
>
> Process 1: "FOO"
> Process 2: "FOO"
> Process 3: Error - File does not exist
> Process 4: "BAR"
>
> Its interesting in that it allows for Unix-style rename() and
> unlink() behavior, but with a race condition. Without Stephan's
> two MoveFile() trick and the FILE_SHARE_DELETE flag, however,
> the result would be Access Denied. Are the places in the backend
> that use rename() and unlink() renaming and unlinking files that
> are only opened for a brief moment by other backends?
I think we are better off looping over
MoveFileEx(MOVEFILE_REPLACE_EXISTING) until the file isn't opened by
anyone. That localizes the changes to rename only and not out to all
the opens.
The open failure loops when the file isn't there seem much worse.
I am a little concerned about starving the rename when there is a lot of
activity but I don't see a better solution.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073