我正在使用open、read和close进行一些基本的文件读取(文件以O_RDONLY访问模式打开)。
当关闭文件时,我想不到一个好的方法来处理可能出现的文件关闭错误,以确保文件正确关闭。
有什么建议吗?
我正在使用open、read和close进行一些基本的文件读取(文件以O_RDONLY访问模式打开)。
当关闭文件时,我想不到一个好的方法来处理可能出现的文件关闭错误,以确保文件正确关闭。
有什么建议吗?
close
失败了,它也会成功。这有几个原因。close
在某些操作系统上开始失败的一个主要原因是AFS。AFS是一个来自80年代的分布式文件系统,具有有趣的语义——所有写操作都在本地缓存中完成,并且当您关闭文件时,数据将写入服务器。AFS还使用了到期的令牌进行加密身份验证。因此,您可能会遇到这样一个有趣的情况:您对文件所做的所有写操作都是在您的令牌有效期内完成的,但实际上与文件服务器通信的close
却使用过期的令牌完成,这意味着您写入本地缓存的所有数据都会丢失。这就是为什么close
需要向用户传达出现问题的原因。大多数文件编辑器都可以正确处理此问题(例如Emacs拒绝将缓冲区标记为未修改),但我很少看到其他应用程序能够处理此问题。close
实际上无法失败。close
在exit
、exec
(文件描述符关闭)和崩溃(核心转储)期间是隐含的。这些都是不能失败的情况。您不能让exit
或崩溃因为关闭文件描述符失败而失败。如果exit
失败怎么办?崩溃呢?如果崩溃也失败了,我们在这之后该去哪里?另外,由于几乎没有人检查close
的错误,如果失败是常见的,您将面临文件描述符泄漏和信息泄漏的风险(假设我们在生成非特权进程之前未能关闭某些文件描述符)。所有这些对于操作系统来说都太危险了,所以我看过的所有操作系统(*BSD、Linux、Solaris)即使底层文件系统关闭操作失败,也会关闭文件描述符。close
并忽略其返回的任何错误即可。如果您有一种优雅的方法来处理它失败的情况,例如编辑器,则可以向用户发送消息并让用户解决问题并重新打开文件、写入数据并尝试再次关闭。不要在循环或其他方式中自动执行任何操作。应用程序中的close
错误超出了您的控制范围。我想最好的方法是重试几次,每次尝试之间有一些短暂的延迟,然后记录问题并继续。
close()函数的手册页面提到EINTR
可能是一个错误,这就是为什么重新尝试可以帮助解决问题。
如果你的程序即将退出,我不会太担心这种类型的错误检查,因为任何你分配的资源都将被操作系统释放(在大多数/典型的桌面/服务器平台上)。
close()
多次似乎是一个不好的主意:https://lkml.org/lkml/2002/7/17/165 - alkclose
返回错误的操作系统中(这本身就是一个糟糕的想法),文件描述符也会在出错时关闭。再次调用close
要么不起作用,要么关闭其他线程打开的不相关的文件描述符。 - Art