I can't think of any case, except if you are too lazy to pass a file descriptor to another process, and its easier to pass the name (which cannot be ruled out, it is easier!). You can't safely close and reopen the file, or it might have been modified.

There is still a possibility that an attacker opens the file before you unlink it and starts writing to it, which O_TMPFILE gets rid of as it never has a name so can never be opened.

How about whenever you're writing a non=temporary file? I do this all the time:

1. Create temporary file in the same directory as the target path.

2. Write and fsync the temporary file

3. Rename the temporary file to the target filename

Oh, and on Linux you can open even deleted files by using /proc/<N>/fd/<M>. It may look like a symlink, but it's not.

You can create files form the fd you get from O_TMPFILE it turns out http://lwn.net/SubscriberLink/562488/3c6d56bef275c0b4/

OK that's a good reason!

Does every program which accepts filenames also accept file descriptors? I can definitely see the use of having a name to pass around.

On Linux at least (not sure about OpenBSD), every open file has a name somewhere in /proc, so you could pass that.

Which defeats having a flag for an "invisible" temp file, since it'll still be visible (and accessible) in /proc.

The case where a name is required is where you want to rename or link the temporary file to a new, permanent name in the filesystem.

It's also useful for debugging. If the file has a name, you can look at the file while the program is stopped in a debugger.