[Python-3000] Py3k_struni additional test failures under cygwin (original) (raw)

Joe Smith unknown_kev_cat at hotmail.com
Tue Jul 31 20:34:27 CEST 2007

"Guido van Rossum" <guido at python.org> wrote in message news:ca471dc20707311106v696b3c7an67939bd802b81176 at mail.gmail.com...

On 7/31/07, Joe Smith <unknownkevcat 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.

My understanding is that POSIX does not require that ability.

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.

Exactly. That is exactly what they do.

The claim was that this meets the POSIX standard. Looking closely, it looks like it does not.

POSIX says:

When the file's link count becomes 0 and no process has the file open, the space occupied by the file shall be freed and the file shall no longer be accessible. If one or more processes have the file open when the last link is removed, the link shall be removed before unlink() returns, but the removal of the file contents shall be postponed until all references to the file are closed.

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.

Exactly the issue. I see the problem here is cygwin's partial POSIX complience. However, Windows NT had a design goal of allowing a complient implementation of POSIX to be implmented in a subsystem (along with userespace utilities).

So it should be possible to get unlink() to work as like a POSIX unlink using raw NT kernel calls. Since Cygwin has dropped support for pre-NT systems, swithing to that seems to be the correct thing to do.

I'll discuss this with the cygwin team.

Regardless, the exact same issue will likely exist on the windows side. It seems likely that a fix for the Windows side may fix the cygwin issue.

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