c - 如何关闭文件？

Question

经过多年的经验，我与Posix和平相处。

然后，我从Linus Torvalds大约在2002年阅读了this消息:

int ret;
do {
    ret = close(fd);
} while(ret == -1 && errno != EBADF);

不。

以上是

(a) not portable

(b) not current practice

“不可移植”部分来自以下事实:
out)，一个线程环境，内核确实在其中关闭了FD
如果出现错误，则可能已将FD有效地(由内核)重新使用了
其他线程，第二次关闭FD是一个BUG。

不仅循环直到EBADF无法移植，而且任何循环都是由于种族条件，如果我没有把这些事情视为理所当然而“和平”，我可能会注意到。

但是，在GCC C++标准库实现basic_file_stdio.cc中，我们有

    do
      __err = fclose(_M_cfile);
    while (__err && errno == EINTR);

该库的主要目标是Linux，但似乎并没有注意Linus。

据我了解，EINTR仅在系统调用阻塞之后发生，这意味着内核在开始任何被中断的工作之前已收到释放描述符的请求。因此，无需循环。确实，SA_RESTART信号行为不适用于close并默认情况下会生成这样的循环，这恰恰是因为它是不安全的。

那么，这是一个标准的库错误，对吧？在C++应用程序关闭的每个文件上。

编辑:为了避免在某些专家提出答案之前引起过多的警报，我应该注意 close 似乎仅在特定情况下才被阻止，也许它们都不适用于常规文件。目前尚不清楚所有细节，但如果不选择EINTR或close进行选择，则不应从fcntl中看到setsockopt。但是，这种可能性使通用库代码更加危险。

Answer 1

对于POSIX，R..的answer to a related question非常清晰简洁:close()是不可重启的特殊情况，不应使用循环。

这让我感到惊讶，因此我决定描述我的发现，然后总结我的结论并最终选择解决方案。

这不是一个真正的答案。将其视为更像其他程序员的观点，包括该观点背后的推理。

POSIX.1-2001和POSIX.1-2008描述了可能出现的三个可能的errno值:EBADF，EINTR和EIO。 EINTR和EIO之后的描述符状态为“未指定”，这意味着它可能已关闭，也可能未关闭。 EBADF表示fd不是有效的描述符。换句话说，POSIX.1明确建议使用

    if (close(fd) == -1) {
        /* An error occurred, see 'errno'. */
    }

无需任何重试循环即可关闭文件描述符。

(即使提到的奥斯汀集团defect #519 R ..也无助于从close()错误中恢复:即使描述符本身保持打开状态，它也未指定在EINTR错误之后是否可能有任何I/O。)

对于Linux，close()系统调用是在fs/open.c中定义的，fs/file.c中的__do_close()管理描述符表锁定，而fs/open.c中的filp_close()则负责细节处理。

总而言之，首先无条件地从表中删除描述符条目，然后是特定于文件系统的刷新(f_op->flush())，然后是通知(dnotify/fsnotify钩子(Hook))，最后是删除任何记录或文件锁。 (大多数本地文件系统(例如ext2，ext3，ext4，xfs，bfs，tmpfs等)都没有->flush()，因此，给定有效的描述符，close()不会失败。只有ecryptfs，exofs，fuses，fuse，cifs和nfs才具有->flush()处理程序据我所知，在Linux-3.13.6中。)

这确实意味着在Linux中，如果在->flush()期间特定于文件系统的close()处理程序中发生写入错误，则无法重试；否则，请重试。就像Torvalds所说的那样，文件描述符总是关闭的。

FreeBSD的 close() 手册页描述了完全相同的行为。

OpenBSD或Mac OS X close()手册页都没有描述在出现错误时是否关闭了描述符，但是我相信它们共享FreeBSD的行为。

在我看来，不需要或不需要循环就可以安全地关闭文件描述符。但是，close()仍可能返回错误。
errno == EBADF指示文件描述符已关闭。如果我的代码意外地遇到了这种情况，对我来说，这表明代码逻辑中存在重大错误，并且该过程应正常退出；否则，请执行以下步骤:我宁愿进程死掉也不愿产生垃圾。

任何其他errno值都表明在确定文件状态时出错。在Linux中，这肯定是与将所有剩余数据刷新到实际存储有关的错误。特别是，我可以想象ENOMEM在没有空间缓冲数据的情况下，EIO如果无法将数据发送或写入实际设备或媒体，EPIPE如果失去与存储设备的连接，ENOSPC如果存储已经存在完全保留未刷新的数据，依此类推。如果该文件是日志文件，我将让进程报告失败并正常退出。如果文件内容在内存中仍然可用，我将删除(取消链接)整个文件，然后重试。否则，我会向用户报告失败。

(请记住，在Linux和FreeBSD中，在错误情况下您不会“泄漏”文件描述符；即使发生错误，也保证它们会被关闭。我假设我可能使用的所有其他操作系统的行为都相同。)

从现在开始我将使用的辅助功能将类似于

#include <unistd.h>
#include <errno.h>

/**
 * closefd - close file descriptor and return error (errno) code
 *
 * @descriptor: file descriptor to close
 *
 * Actual errno will stay unmodified.
*/
static int closefd(const int descriptor)
{
    int saved_errno, result;

    if (descriptor == -1)
        return EBADF;

    saved_errno = errno;

    result = close(descriptor);
    if (result == -1)
        result = errno;

    errno = saved_errno;
    return result;
}

我知道以上内容在Linux和FreeBSD上都是安全的，并且我认为在所有其他POSIX-y系统上都是安全的。如果遇到的不是，我可以简单地用自定义版本替换上面的内容，并将其包装在适合该OS的#ifdef中。它使errno保持不变的原因仅仅是我的编码风格的一个怪癖。它使短路错误路径更短(重复代码更少)。

如果我要关闭包含重要用户信息的文件，则在关闭之前我将对其进行 fsync() or fdatasync() 操作。这样可以确保数据访问存储，但与正常操作相比也会造成延迟；因此，我不会对普通数据文件执行此操作。

除非我将 unlink() ing关闭，否则将检查closefd()返回值并采取相应措施。如果我可以轻松地重试，则可以，但是最多一次或两次。对于日志文件和生成/流式传输的文件，我仅警告用户。

我想提醒所有阅读本文的人，我们不能使任何事情都完全可靠。只是不可能。我能做的，我认为应该做的是，尽可能可靠地检测何时发生错误。如果我们可以轻松地进行资源使用重试，那么我们应该这样做。在所有情况下，我们都应确保将通知(关于错误)传播给实际的人工用户。让人们担心在重试该操作之前是否需要执行某些其他操作(可能很复杂)。毕竟，许多工具仅用作较大任务的一部分，而最佳操作通常取决于该较大任务。