Reply to thread

Message: [QUOTE="David Bolen, post: 1716756"] I can only speak for NT, but I have seen timing issues in the past where there is some additional latency imposed by the system between when I release all references to a file and when it can be removed from the filesystem by the same process. This has affected me in C code as well as Python. Perhaps you're running into the same thing, although for me it normally showed up as a permission denied error. Sometimes the higher level Python I/O exceptions can be a bit vague (by their nature, a lot of underlying Win32 error codes eventually get translated into a far fewer number of C RTL error codes, which in turn bubble up as Python exceptions). One thing you could try, depending on the operation in question, is to replace the Python operation (such as os.remove) with a matching win32all module operation (such as win32file.DeleteFile), which should raise a more specific exception. In my past experiences, the most practical, albeit inelegant, workaround was to retry a failed removal operation after several seconds. Definitely a kluge, but I was never able to isolate any more well-defined approach. This of course assumes that you don't really have a threading race condition under which you still do hold active handles to the file that you are trying to remove. The fact that you're getting back an invalid handle error certainly makes it seem that you make still be looking at a race condition or inter-thread data corruption within your application. Depending on the structure of the application, if you can wrap (or if you have already) all access to your file handles through a common class you should be able to instrument it in order to at least get some sort of trace as to how they are accessed, and perhaps catch one of the failures. But as you probably know, debugging this sort of thing can be nasty, particularly if it's truly sporadic in nature. -- David [/QUOTE]

Verification