This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients Carl Osterwisch, Gabi.Davar, John Florian, chary314, dabrahams, davide.rizzo, dlenski, eric.araujo, eric.smith, eryksun, ethan smith, jaraco, jwilk, martin.panter, ncoghlan, njs, paul.moore, piotr.dobrogost, pitrou, r.david.murray, sbt, steve.dower, tim.golden, zach.ware
Date 2020-09-09.20:47:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1599684431.07.0.355345240347.issue14243@roundup.psfhosted.org>
In-reply-to
Content
> Why do we need to use this O_TEMPORARY flag at all?

Using the O_TEMPORARY flag isn't necessary, but it's usually preferred because it ensures the file gets deleted even if the process is terminated abruptly. However, it opens the file with delete access, and most Windows programs don't share delete access for normal file opens. This can be worked around in Python code by using an opener that calls CreateFileW with delete-access sharing. But it can't be worked around in general. 

I prefer to provide a way to omit O_TEMPORARY, but still use it by default. When it's omitted, I'd also like to be able to close the file within the context block without deleting it, for which one use case is to reopen the file in a program that doesn't share read or write access. A new delete_on_close option would support this case, in addition to providing a way to omit the O_TEMPORARY flag. For example:
    
    with tempfile.NamedTemporaryFile(delete_on_close=False) as f:
        f.close()
        subprocess.run([cmd, f.name])

The file will still be deleted by the context manager, but the tradeoff is that it's not as reliable as the default delete-on-close behavior that uses the O_TEMPORARY flag.
History
Date User Action Args
2020-09-09 20:47:11eryksunsetrecipients: + eryksun, paul.moore, jaraco, ncoghlan, pitrou, eric.smith, tim.golden, jwilk, eric.araujo, r.david.murray, njs, dabrahams, davide.rizzo, sbt, Gabi.Davar, martin.panter, piotr.dobrogost, zach.ware, dlenski, steve.dower, Carl Osterwisch, ethan smith, John Florian, chary314
2020-09-09 20:47:11eryksunsetmessageid: <1599684431.07.0.355345240347.issue14243@roundup.psfhosted.org>
2020-09-09 20:47:11eryksunlinkissue14243 messages
2020-09-09 20:47:10eryksuncreate