We had a couple of failures in a server application that we cannot yet
reproduce in a simple case. Analysis of the code suggests that the
only possible explanation is that the following occurs,

os.remove(x)
.... stuff
if os.path.isfile(x):
    raise "Ooops, how did we get here?"
file(x, "wb").write(content)

We end up in the raise. By the time we get to look at the system the
file is actually gone, presumably because of the os.remove.

The "stuff" is a handful of lines of code which don't take any
significant time to perform. There are no "try" blocks to mask a
failure in the os.remove call.

The application is multithreaded so it is possible that another thread
writes to the file between the "remove" and the "isfile", but at the
end of the failure the file is actually not on the filesystem and I
don't believe there is a way that the file could be removed again in
this scenario.

Regards,

   http://msdn2.microsoft.com/En-US/library/aa363915.aspx

No suggestion there that it might return before completion,
but I'd be surprised if it did.

The most likely bet would seem to be a race condition
as you suggest below. Doesn't have to be from a thread
in your program, although I assume you know best about
your own filesystem ;)

Another possibility -- I suppose, though without any
authority -- is that the .remove is silently swallowing
an error (ie failing at OS level without telling Python
so no exception is raised). Much more likely is that
somewhere in that "...stuff" is something which
inadvertently recreates the file.

Don't suppose you've got some kind of flashy software
running which intercepts OS file-manipulation calls for
Virus or Archiving purposes?