[Python-3000] Py3k_struni additional test failures under cygwin
Guido van Rossum
guido at python.org
Tue Jul 31 20:06:58 CEST 2007
On 7/31/07, Joe Smith <unknown_kev_cat at hotmail.com> 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/)
More information about the Python-3000
mailing list