If you press Ctrl+C at the wrong moment, NamedTemporaryFile won't delete the
temporary file. To reproduce, you can try this script:

    import tempfile
    while True:
        with tempfile.NamedTemporaryFile(dir='.'):
            pass

I get a stray temporary file when I press Ctrl+C about 40% of the time.

Nick, is this related to the bug where the "finally" portion of a context manager isn't guaranteed to be called?

Aye, this is a specific case of the general issue noted in https://bugs.python.org/issue29988 (while it may be partially mitigated by https://bugs.python.org/issue32949, it isn't a guarantee)

I think issue29988 is unrelated, or at least not the whole story.

These are samples of tracebacks I see when the file is left behind:

  Traceback (most recent call last):
    File "test-tmpfile.py", line 4, in <module>
      with tempfile.NamedTemporaryFile(dir='.'):
    File "/opt/python/lib/python3.8/tempfile.py", line 548, in NamedTemporaryFile
      (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags, output_type)
    File "/opt/python/lib/python3.8/tempfile.py", line 258, in _mkstemp_inner
      fd = _os.open(file, flags, 0o600)
  KeyboardInterrupt
  
  Traceback (most recent call last):
    File "test-tmpfile.py", line 4, in <module>
      with tempfile.NamedTemporaryFile(dir='.'):
    File "/opt/python/lib/python3.8/tempfile.py", line 548, in NamedTemporaryFile
      (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags, output_type)
    File "/opt/python/lib/python3.8/tempfile.py", line 269, in _mkstemp_inner
      return (fd, _os.path.abspath(file))
    File "/opt/python/lib/python3.8/posixpath.py", line 371, in abspath
      path = os.fspath(path)
  KeyboardInterrupt
  
  Traceback (most recent call last):
    File "test-tmpfile.py", line 4, in <module>
      with tempfile.NamedTemporaryFile(dir='.'):
    File "/opt/python/lib/python3.8/tempfile.py", line 548, in NamedTemporaryFile
      (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags, output_type)
    File "/opt/python/lib/python3.8/tempfile.py", line 269, in _mkstemp_inner
      return (fd, _os.path.abspath(file))
    File "/opt/python/lib/python3.8/posixpath.py", line 378, in abspath
      return normpath(path)
    File "/opt/python/lib/python3.8/posixpath.py", line 355, in normpath
      if comp in (empty, dot):
  KeyboardInterrupt

In all cases the interrupt happened in the NamedTemporaryFile function,
so before __enter__/__exit__ would have chance to do its job.

It's still the same problem - the underlying issue is that the with statement machinery doesn't currently mask signals in the main thread while __enter__ and __exit__ are running, so __enter__ and __exit__ methods written in Python are also at risk of being interrupted at an inopportune point.

This means that even "with closing(open('filename')) as f: ..." is more at risk of leaving the file open until __del__ cleans it up than the version that calls open() directly.

So if this a concern that an application needs to worry about, then it currently needs to adopt a more complicated execution structure where:

1. The main thread launches a subthread that actually does all the work.
2. The main thread immediately drops into "active_thread.join()" (which can be interrupted by Ctrl-C)

Unfortunately, this scheme *doesn't* work for applications where the application itself needs to detect and handling signals other than Ctrl-C.

Nick, what Jakub is saying is that 'with' hasn't even gotten involved yet: we're still executing the NamedTemporaryFile constructor, so the object hasn't been returned for 'with' to operate on yet.  In other words, NamedTemporaryFile.__init__ isn't safe against ctl-C when it calls _mkstemp, which is obvious by inspection since it isn't inside the try/except.

resolution: duplicate
stage: resolved