如何关闭文件？

Question

经过多年的经验,我觉得与Posix和平相处.

然后我从Linus Torvalds 读到这条消息,大约2002年:

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

没有.

以上是

(a)不便携

(b)不是现行做法

"不可移植"部分来自这样一个事实:(正如有人指出的那样),一个线程环境,其中内核确实关闭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默认不适用于并生成这样的循环,正是因为它不安全.

这是一个标准的库bug,对吗？在每个由C++应用程序关闭的文件上.

编辑:为了避免在一些大师出现回答之前引起太多警报,我应该注意到,close在特定情况下似乎只允许阻止,可能没有一个适用于常规文件.我不是在所有的细节清晰,但你不应该看到EINTR从close没有通过选择到的东西fcntl或setsockopt.然而,这种可能性使通用库代码更加危险.

Answer 1

关于POSIX,R .. 对相关问题的回答非常简洁明了:close()是一个不可重启的特殊情况,不应该使用循环.

这对我来说是令人惊讶的,所以我决定描述我的发现,然后是我的结论和最终选择的解决方案.

这不是一个真正的答案.考虑这更像是一个程序员的意见,包括该意见背后的推理.

POSIX.1-2001与POSIX.1-2008描述可能出现的三种可能的错误值:EBADF,EINTR,和EIO.描述符状态在EINTR和之后EIO是"未指定",这意味着它可能已经关闭,也可能没有关闭.EBADF表示fd不是有效的描述符.换句话说,POSIX.1明确建议使用

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

没有任何重试循环来关闭文件描述符.

(即使奥斯汀集团的缺陷#519 R ..提到,也没有帮助从close()错误中恢复:EINTR即使描述符本身保持打开状态,它也会指出错误后是否有可能存在任何I/O. )

对于Linux,close()系统调用中定义FS/open.c,与__do_close()在FS/file.c管理描述符表锁定,并且filp_close()早在FS/open.c考虑的细节.

总之,首先无条件地从表中删除描述符条目,然后是文件系统特定的flushing(f_op->flush()),然后是通知(dnotify/fsnotify hook),最后删除任何记录或文件锁.(大多数本地文件系统,如ext2,ext3,ext4,xfs,bfs,tmpfs等等,没有->flush(),所以给定一个有效的描述符,close()不能失败.只有ecryptfs,exofs,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系统上都是安全的.如果我遇到一个不是,我可以简单地用自定义版本替换上面的内容,将其包装在适合#ifdef该操作系统的版本中.保持errno不变的原因只是我编码风格的一个怪癖; 它使短路错误路径更短(重复代码更少).

如果我要关闭包含重要用户信息的文件,我会在关闭之前做一个fsync()或者fdatasync()一个.这确保了数据到达存储器,但与正常操作相比也导致延迟; 因此我不会对普通数据文件这样做.

除非我将在unlink()荷兰国际集团关闭的文件,我会检查closefd()返回值,并采取相应的行动.如果我可以轻松重试,我会,但最多一次或两次.对于日志文件和生成/流式文件,我只警告用户.

我想提醒任何读到这一点的人,我们不能做出任何完全可靠的东西 ; 这是不可能的.我们能做的,我认为应该做的是尽可能可靠地检测错误发生的时间.如果我们可以轻松地使用可忽略的资源重用,我们应该.在所有情况下,我们都应确保将通知(关于错误)传播给实际的人类用户.让人担心是否需要在重试操作之前完成其他可能复杂的操作.毕竟,许多工具仅作为更大任务的一部分使用,最佳行动方案通常取决于更大的任务.