[Python-3000] Py3k_struni additional test failures under cygwin

[Joe Smith]

"Guido van Rossum" <guido at python.org> wrote in message 
news:ca471dc20707311106v696b3c7an67939bd802b81176 at mail.gmail.com...
> 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.

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/)