Eryk Sun <eryk...@gmail.com> added the comment:
> For this case, I think the best thing we can probably do is change the
> default share mode for _all_ opens to include FILE_SHARE_DELETE.
The C runtime doesn't provide a way to share delete access, except for the
O_TEMPORARY flag, so Python would have to re-implement open(). Also, this
doesn't help with re-opening a temporary file in another process since most
programs do not share file delete access.
There could be an option to enable a context-manager delete that's independent
of closing the file. For example, if delete=True and delete_on_close=False,
then _TemporaryFileCloser.close doesn't delete the file. Instead the file would
be deleted via os.unlink in _TemporaryFileWrapper.__exit__. The default would
be delete=True and delete_on_close=True, which would use the O_TEMPORARY flag
in Windows. Combining delete=False with delete_on_close=True would raise a
ValueError.
> bringing the default Windows behaviour slightly more in line with
> how POSIX likes to do things.
In Windows 10, using FILE_SHARE_DELETE is even closer to POSIX behavior when
the filesystem is NTFS, which supports POSIX delete semantics by renaming the
file to a hidden system directory ("\$Extend\$Deleted") and setting its delete
disposition. WinAPI DeleteFileW has been updated to use POSIX semantics if the
filesystem supports it:
>>> f = tempfile.NamedTemporaryFile()
>>> h = msvcrt.get_osfhandle(f.fileno())
>>> os.unlink(f.name)
>>> info = GetFileInformationByHandleEx(h, FileStandardInfo)
>>> info['DeletePending']
True
>>> GetFinalPathNameByHandle(h, 0)
'\\\\?\\C:\\$Extend\\$Deleted\\001800000002C4F4301F419F'
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue14243>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
