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 -- http://mail.python.org/mailman/listinfo/python-list