如果close(2)失败并返回EIO，文件描述符是否仍会被删除？

Question

如果close(2)系统调用因EIO而失败，文件描述符是否仍会被删除？

如果是，是否不能通过稍后重试来处理伪IO错误？如果不是，应该如何防止文件描述符泄漏？

Answer 1

这是一个棘手的问题。然而，POSIX标准在对close()的描述中确实涵盖了它

如果close()被要捕获的信号中断，它将返回-1，错误号设置为EINTR，文件状态未指定。如果在close()期间从文件系统读取或写入文件系统时发生I/O错误，则可能会返回-1，并将errno设置为EIO；如果返回此错误，则fildes的状态为未指定。

因此，标准未指定文件描述符的状态。

对于大多数实际用途，它是关闭的；即使文件描述符是正式打开的，您也几乎不能对它做什么。您可以尝试一个无害的操作(如fcntl()和F_GETFL)，并查看是否返回了EBADF，这表明描述符已正式关闭。但是，如果它是打开的，并且EIO错误的原因是永久性的，那么每次您尝试使用它做任何事情(可能包括fcntl()调用)时，都可能得到EIO。您可能会也可能永远不会得到另一个类似打开的操作返回的相同描述符。如果死文件描述符是打开但不可关闭的，那么即使是dup2()也不清楚是否可以成功地将该死文件描述符指定为目标。