On 7/31/07, Joe Smith <[EMAIL PROTECTED]> wrote: > Hmm... The documentation for Cygwin's unlink() implies that it should > function the same as a POSIX unlink() except perhaps if a non-Cygwin process > has an open handle for it without the correct attributes. I see nothing on > my system that would have done that. (No indexing service or virus scanner) > So that implies that at the time Python is trying to create the file, it > still has an open handle for it. Either that, or something besides Python is > opening the file without my knowledge.
Regular Windows typically won't let you remove a file when you still have it open. Is this also a restriction on CYGWIN? I don't know anything about CYGWIN but I could imagine that they allow unlink() to succeed when there's still a file descriptor referencing it, and that they will delete the file when you close it. But if that fd is never closed the file is probably in weird state. Anyway, before we start speculating more, you probably need to find a source of more CYGWIN expertise elsewhere -- it's rather thin here. Rewriting those tests to use a mroe random temporary file might also be an option, as long as you make sure to clean up (use try/finally or setUp/tearDown). -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
