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