Can os.remove followed by os.path.isfile disagree?
tundra at tundraware.com
Wed Jun 6 17:11:35 CEST 2007
ppaterson at gmail.com wrote:
> 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.
This sure sounds like a thread race condition. In theory, the os.remove call
failing to actually remove the file before returning might also do this,
but it seems unlikely that a bug that blatant in a fundamental OS call could
survive very long, even in Windoze.
I'd take the time to really examine the multiple threads of work you're running
to make sure one of them isn't removing the file just as another creates it.
Better still, use a locking semaphore around the code the creates/deletes the file
to guarantee mutual exclusion.
More information about the Python-list