[Python-3000] Py3k_struni additional test failures under cygwin

[Joe Smith]

""Martin v. Löwis"" <martin at v.loewis.de> wrote in message 
news:46AF90BE.3050803 at v.loewis.de...
>>> 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.
> Not exactly; it's not possible with Win32 to do that.

Um. It is indeed possible to mark a file for deletion on close. The 
requirement is that all file handles have SHARED_DELETE. This is one of the 
things Cywin has tried. It works fine except when a Windows app has opened 
the file without that flag.
To prevent the name clashes, movment to the recycle bin is required.

> What they do instead is
> 1. try to delete the file. If that fails for sharing
>   violation, try 2.
> 2. move the file to the recycle bin, and set the
>   "delete" disposition flag on the file, this will
>   cause it to be removed from the recycle bin when
>   the last handle is closed.

That is what they do with the latest patches. It is pretty much equivent to 
the POSIX system.
That requires Native NT Calls, and is not part of win32. It is equivlent to 
marking the file for
deletion on close, except the other handles do not need to have 
shared_delete.
The moving the file to the recycle bin just gets the file out of the way.

But for what it is worth, the next cygwin release will be doing exactly what 
is described above.
So to Python it will look and act *almost* exactly like POSIX. It should fix 
the problem.

GVR: The move to recycle bin is more or less a rename() call, except I 
belive it has special support for avoiding name conflicts.