homepage

Logged In: YES 
user_id=31435
The problem is that there's no reason to believe anything he
did here _does_ leave files open. I can confirm the
"permission denied" symptom, and even if I arrange for the
call to "touch" to run a touch.bat that doesn't even look at
the filename passed to it (let alone open or modify the file).
I also see a large number of errors of this sort:
Exception in thread Thread-8:
Traceback (most recent call last):
 File "C:\python24\lib\threading.py", line 442, in __bootstrap
 self.run()
 File "osremove.py", line 21, in run
 touch(filename)
 File "osremove.py", line 8, in touch
 stdin=None, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
 File "C:\python24\lib\subprocess.py", line 490, in __init__
 _cleanup()
 File "C:\python24\lib\subprocess.py", line 398, in _cleanup
 inst.poll()
 File "C:\python24\lib\subprocess.py", line 739, in poll
 _active.remove(self)
ValueError: list.remove(x): x not in list
Those are clearly due to subprocess.py internals on Windows,
where the poll() and wait() methods and the module internal
_cleanup() function aren't called in mutually threadsafe
ways. _Those_ errors can be stopped by commenting out the
_cleanup() call at the start of Popen.__init__() (think
about what happens when multiple threads call _cleanup() at
overlapping times on Windows: all those threads can end up
trying to remove the same items from _active, but only one
thread per item can succeed).
The "permission denied" errors persist, though.
So there's at least one class of subprocess.py Windows bugs
here, and another class of Windows mysteries. I believe
subprocess.py is a red herring wrt the latter, though. For
example, I see much the same if I use os.system() to run
`touch` instead.