[re tests which fail because something's holding a file open with SHARE_DELETE]
Well I've tried my best, but I can't come up with a solution which guarantees to overcome this obstacle. I set up a fairly aggressive directory watcher which, when it sees a test file being created, takes a SHARE_DELETE handle on it and releases it immediately. (Guessing that this is what the other apps are doing). Running the test suite from HEAD, this generates all manner of access-denied type errors as per the original output. I used tempfile to generate a random TESTFN in the current directory rather than the static @test. And implemented the rename-shim discussed previously, renaming to a different random name, courtesy of mktemp. With those in place, most tests run without error. But I'm still getting errors in the same sort of areas which Steven B originally reported. The one error I can't see a way round is the access denied (which manifests as Permission Error) which is the documented result of attempting to open a file with a pending delete -- ie the delete succeeded but hasn't completed yet. An additional complication is that there are hundreds of instances throughout the tests where the test simply calls os.unlink/os.remove to undo the test file. To have some more robust central deletion I had to go through and update 68 tests. I'll keep trying, but in the current state I'm not convinced the situation's improved enough for me to bother uploading a patch. TJG _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
