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.