Can os.remove followed by os.path.isfile disagree?

Paul Paterson ppaterson at gmail.com
Wed Jun 6 11:46:29 EDT 2007


Thanks for the quick and detailed response!


> 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 ;)

My first thought, after discounting the os.remove early return, was
that it has to be from a thread in our application. But,

a) it is highly unlikely due to the way tasks are scheduled
b) even if it did occur I don't see a code path that ends with the
file not there

But, until I read the next part of your note, it was still the only
credible explanation ...

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

... I'm wondering if this is the culprit. I now recall that the
Spambayes project saw a weird error due to Google Desktop Search where
GDS would intervene at such a low level that some file system level
"invariants" ... aren't! I don't remember the details but I think you
delete or create a file and GDS jumps in to backup / index it and you
don't have the access you thought you had moments ago.

I don't think GDS is running on this server but it is running a lot of
other enterprise monitoring apps and maybe they are doing a similar
thing.

I'm off to investigate more on this front!

Thanks,

Paul





More information about the Python-list mailing list