Can os.remove followed by os.path.isfile disagree?
mail at timgolden.me.uk
Wed Jun 6 16:53:56 CEST 2007
ppaterson at gmail.com wrote:
> Can os.path.isfile(x) ever return True after os.remove(x) has
> successfully completed? (Windows 2003, Python 2.3)
> 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,
> .... 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.
The os.remove implementation (in posixmodule.c) uses
the DeleteFileW/A API call (depending on Unicode or not):
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?
More information about the Python-list