Guaranteed file deletion upon program termination (C/C++)

Question

Win32\'s CreateFile has FILE_FLAG_DELETE_ON_CLOSE, but I\'m on Linux.

I want to open a temporary file which will always be deleted upon program terminat

Answer 1

Maybe someone suggested this already, but I'm unable to spot it, given all your requirements, the best I can think of is to have the filename somehow communicated to a parent process, such as a start-script, which will clean up after the process dies, had it failed to do so. This is perhaps mostly known as a watchdog, but then with the more common use case added to kill and/or restart the process when it somehow fails.

If your parent process dies as well, you're pretty much out of luck, but most script environments are fairly robust and rarely die unless the script is broken, which is often easier to keep correct than a program.

Answer 2

In the past, I have build a "temporary file manager" that kept track of temporary files.

One would request a temporary file name from the manager and this name was registered.

Once you don't need the temporary file name any more, you inform the manager and the filename is unregistered.

Upon receipt of a termination signal, all the registered temporary files were destroyed.

Temporary filenames were UUID based to avoid collisions.

Answer 3

The requirement that the name remains visible while the process is running makes this hard to achieve. Can you revisit that requirement?

If not, then there probably isn't a perfect solution. I would consider combining a signal handling strategy with what Kamil Kisiel suggests. You could keep track of the signal handlers installed before you install your signal handlers. If the default handler is SIG_IGN, you wouldn't normally install your own handler; if it is SIG_DFL, you would remember that; if it is something else - a user-defined signal handler - you would remember that pointer, and install your own. When your handler was called, you'd do whatever you need to do, and then call the remembered handler, thus chaining the handlers. You would also install an atexit() handler. You would also document that you do this, and the signals for which you do it.

Note that signal handling is an imperfect strategy; SIGKILL cannot be caught, and the atexit() handler won't be called, and the file will be left around.

David Segond's suggestion - a temporary file name daemon - is interesting. For simple processes, it is sufficient; if the process requesting the temporary file forks and expects the child to own the file thereafter (and exits) then the daemon has a problem detecting when the last process using it dies - because it doesn't automatically know the processes that have it open.

Answer 4

You could have the process fork after creating the file, and then wait on the child to close, and then the parent can unlink the file and exit.

Answer 5

I just joined stackoverflow and found you here :)

If you're problem is to manage mq files and keep them from piling up, you don't really need to guarantee file deletion upon termination. If you just wanted to useless files from piling up, than keeping a journal may be all you need. Add an entry to the journal file after a mq is opened, another entry when it is closed, and when your library is initialized, check for inconsistency in the journal and take whatever action needed to correct the inconsistency. If you worry about crashing when mq_open/mq_close is being called, you can also add an journal entry just before those functions are called.

Answer 6

If you're just making a temporary file, just create it in /tmp or a subdirectory thereof. Then make a best effort to remove it when done through atexit(3) or similar. As long as you use unique names picked through mkstemp(3) or similar even if it fails to be deleted because of a program crash, you don't risk reading it again on subsequent runs or other such conditions.

At that point it's just a system-level problem of keeping /tmp clean. Most distros wipe it on boot or shutdown, or run a regular cronjob to delete old files.