Here is a very short program to demonstrate what I'm seeing:

>>> import tempfile
>>> import os
>>> with tempfile.NamedTemporaryFile(delete=True) as fp:
...     print(fp.name)
...     os.system('rm {}'.format(fp.name))
/tmp/tmpomw0udc6
0
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
  File "/usr/local/lib/python3.6/tempfile.py", line 502, in __exit__
    self.close()
  File "/usr/local/lib/python3.6/tempfile.py", line 509, in close
    self._closer.close()
  File "/usr/local/lib/python3.6/tempfile.py", line 446, in close
    unlink(self.name)
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tmpomw0udc6'


In my specific use case, I am shelling out to another program (binutils' objcopy) and passing the path of the NamedTemporaryFile as the output file. objcopy apparently deletes the output file if it encounters an error, which causes NamedTemporaryFile's exit method to fail when it tries to delete the file.

While I can work around this by using delete=False and manually doing the cleanup on my own, it's less elegant than being able to rely on the normal context manager exit.

I've just added PR fixing this issue.

any updates on this? :)

some updates?

Deleting non-existent files in /tmp is an indicator of a security hole.
This kind of error must never pass silently.

any updates?

> Deleting non-existent files in /tmp is an indicator 
> of a security hole.

Christian, what is your take on this?

Raymond, I think Richard's approach is problematic at best. 

Richard, you cannot use a NamedTempFile with an external process like that. At least you have to flush the file to disk. Even flushing is not safely portable. The safest and most portable approach is to close the file, call the other process and then unlink the file manually:

with tempfile.NamedTemporaryFile(delete=False) as f:
    try:    
        f.write(b'data')
        f.close()
        subprocess.Popen(['binutil', f.name, ...])
    finally:
        os.unlink(f.name)


It's too bad that close() on a NamedTemporaryFile(delete=True) deletes the files. For your problem it would be beneficial to have __exit__() perform the unlink operation.

He's still going to get an error using your code, Christian.  But if he knows that the file being gone is OK, he can catch and ignore the error.  Having exit do the unlink wouldn't help him; in that case he'd have to wrap the whole 'with' clause in a try/except.

So I think delete=False and handling the error "manually" is the correct solution here, since I doubt we want to add a "already_deleted_ok=False" flag to the API for this limited use case that can be handled with delete=False.

I vote for closing this as rejected.

RDM, I don't see how my example is going to fail. It uses delete=False with an explicit unlink. Please educate me. :)

His problem is that the file has already been deleted by the time the subprocess returns, so the unlink is going to raise an exception.

Thanks for the discussion. I ended up doing something similar to the code snippet Christian posted, except I also had a second try/except FileNotFoundError within the original finally block to catch the case that David pointed out.

In retrospect, I probably should have used TemporaryDirectory since I am using Python 3.5 and because the file I was creating with NamedTemporaryFile was only being used as an output file, not an input file, to the subprocess command.

Ah! I missed the fact that the subprocess removes the file. It's easily fixable, wrap the unlink and catch FileNotFoundError / ENOENT.

See also Issue 27425, about making the deletion step more flexible after the file has been created, which might help here.

I’m not sure about security problems, but IMO failure to remove a temporary file (because it is already gone, or some other reason) is likely to be a programming mistake, so I would not want it silenced.

any conclusion on this? looks like it's a bit stuck

I think we are leaning strongly toward making no change here.