[Python-3000] Py3k_struni additional test failures under cygwin
unknown_kev_cat at hotmail.com
Tue Jul 31 22:02:33 CEST 2007
""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
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
GVR: The move to recycle bin is more or less a rename() call, except I
belive it has special support for avoiding name conflicts.
More information about the Python-3000