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