程序终止时保证文件删除(C/C++)

Win32 CreateFile有FILE_FLAG_DELETE_ON_CLOSE,但我在Linux上.

我想打开一个临时文件,在程序终止时将永远删除该文件.我可以理解,在程序崩溃的情况下,保证这一点可能不切实际,但在任何其他情况下我都希望它能够工作.

我知道RAII.我知道信号.我知道atexit(3).我知道我可以打开文件并立即删除它,文件将保持可访问状态,直到文件描述符关闭(甚至处理崩溃).这些似乎都不是一个完整而直接的解决方案:

RAII:去过那里,完成了:我有一个析构函数删除文件的对象,但如果程序被一个信号终止,则不会调用析构函数.

信号:我正在编写一个低级库,这使得注册信号处理程序变得棘手.例如,如果应用程序本身使用信号怎么办？我不想踩任何脚趾.我可能会考虑巧妙地使用它sigaction(2)来应对......但是还没有充分考虑这种可能性.

atexit(3):显然没用,因为它在异常终止期间没有被调用(例如通过信号).

preemptive unlink(2):这是非常好的,除了我需要文件在文件系统中保持可见(否则系统更难监控/故障排除).

你会在这做什么？

进一步说明

我在原帖中省略了一个细节,我现在意识到应该包含这个细节.在这种情况下,"文件"不是严格意义上的普通文件,而是POSIX消息队列.我通过创建它mq_open().它可以通过mq_close()或关闭close()(前者是我系统中后者的别名).它可以通过系统删除mq_unlink().所有这些使它类似于常规文件,除了我不能选择文件所在的目录.这使得当前最流行的答案(放置文件/tmp)变得不可行,因为"文件"是由系统在容量非常有限的虚拟文件系统中创建的.(我已经/dev/mqueue按照示例安装了虚拟文件系统man mq_overview).

这也解释了为什么我需要保持名称的名称(使立即取消链接方法不可行):"文件"必须在两个或多个进程之间共享.

在进程运行时名称仍然可见的要求使得这很难实现.你能重新审视这个要求吗？

如果没有,那么可能没有一个完美的解决方案.我会考虑将信号处理策略与Kamil Kisiel建议的结合起来.在安装信号处理程序之前,您可以跟踪安装的信号处理程序.如果默认处理程序是SIG_IGN,则通常不会安装自己的处理程序; 如果是SIG_DFL,你会记得那个; 如果它是其他东西 - 用户定义的信号处理程序 - 你会记住该指针,并安装自己的.当你的处理程序被调用时,你会做你需要做的任何事情,然后调用记住的处理程序,从而链接处理程序.您还将安装atexit()处理程序.您还会记录您执行此操作以及执行此操作的信号.

请注意,信号处理是一种不完美的策略; 无法捕获SIGKILL,并且不会调用atexit()处理程序,并且文件将被保留.

David Segond的建议 - 临时文件名守护程序 - 很有趣.对于简单的过程,这就足够了; 如果请求临时文件的进程分叉并且期望子进程此后拥有该文件(并退出),那么该守护进程在检测使用它的最后一个进程何时死亡时会出现问题 - 因为它不会自动知道打开它的进程.

如果您只是创建一个临时文件,只需在其中创建它/tmp或其子目录.然后尽最大努力在完成atexit(3)或类似时将其删除.只要您使用通过mkstemp(3)或类似选择的唯一名称,即使由于程序崩溃而无法删除它,您也不会冒险在后续运行或其他此类条件下再次读取它.

那时,这只是保持/tmp清洁的系统级问题.大多数发行版在启动或关闭时擦除它,或者运行常规cronjob来删除旧文件.