处理的C只读文件关闭错误 [英] Handling C Read Only File Close Errors

问题描述

我在做一些基本的文件使用开放阅读，阅读，和关闭（文件与访问模式O_RDONLY打开）。

I'm doing some basic file reading using open, read, and close (Files are opened with access mode O_RDONLY).

当谈到时间，关闭文件，我想不出来处理可能的文件关闭错误，以确保文件被正确关闭的好方法。

When it comes time to close the file, I can't think of a good way to handle a possible file close error to make sure that the file is closed properly.

有什么建议？

推荐答案

从我的经验关闭甚至会失败时获得成功。有几个方面的原因。

From my experience close will succeed even when it fails. There are several reasons for this.

我怀疑的重要原因闭一只启动失败，在某些操作系统是AFS。 AFS是一个分布式文件系统从有趣的语义80 - 所有的写操作都做一个本地缓存和你的数据被写入到服务器，当你关闭文件。 AFS还加密与时间到期后令牌认证。所以，你可以在你对一个文件中的所有的写操作都做了，而你的令牌是有效的一个有趣的情况结束了，但关闭这实际上跟文件服务器可能是过期的令牌这意味着你写信给本地缓存中的数据丢失完成。这就是为什么关闭来沟通，那出事了用户所需要的。大多数文件的编辑处理这个正确（emacs的拒绝缓冲区标记为不脏，例如），但我很少看到，可以处理这个其他应用程序。

I suspect that one of the big reasons close started to fail on some operating systems was AFS. AFS was a distributed file system from the '80s with interesting semantics - all your writes were done to a local cache and your data was written to the server when you close the file. AFS also was cryptographically authenticated with tokens that expired after a time. So you could end up in an interesting situation where all the writes you did to a file were done while your tokens were valid, but close which actually talked to the file server could be done with expired tokens meaning that all the data you wrote to the local cache was lost. This is why close needed to communicate to the user that something went wrong. Most file editors handle this correctly (emacs refuses to mark the buffer as not dirty, for example), but I've rarely seen other applications that can handle this.

话虽这么说，关闭不能真正失败过。 关闭是退出， EXEC （巫特写时隐上EXEC文件描述符）和核心转储崩溃。这些都是，你不能失败的情况。你不能有退出或崩溃失败，只是因为关闭文件描述符失败。你会怎么办时，退出不成？崩溃？如果崩溃失败了呢？我们在哪里后跑？此外，由于几乎没有人检查错误关闭如果失败是常见的，你会最终文件描述符泄漏和信息泄露（如果我们不能关闭一些文件描述符产卵前一个非特权过程？）。所有这一切都太危险了一个操作系统，以便让所有的操作系​​统我看着（* BSD，Linux和Solaris）关闭，即使底层文件系统关闭操作失败的文件描述符。

That being said, close can't really fail anyway. close is implicit during exit, exec (witch close-on-exec file descriptors) and crashes that dump core. Those are situations where you can't fail. You can't have exit or a crash fail just because closing the file descriptor failed. What would you do when exit fails? Crash? What if crashing fails? Where do we run after that? Also, since almost no one checks for errors in close if failing was common you'd end up with file descriptor leaks and information leaks (what if we fail to close some file descriptor before spawning an unprivileged process?). All this is too dangerous for an operating system to allow so all operating systems I've looked at (*BSD, Linux, Solaris) close the file descriptor even if the underlying filesystem close operation has failed.

在实践中，这意味着你只需要调用关闭，而忽略它返回的任何错误。如果你有处理它失败就像一个编辑优雅的方式做，你可以发送邮件给用户，让用户解决问题，并重新打开该文件，记下数据，并尝试再次关闭。不要自动做任何事情，在一个循环或其他。在错误关闭超出了在应用程序的控制。

In practice this means that you just call close and ignore any errors it returns. If you have a graceful way of handling it failing like editors do you can send a message to the user and let the user resolve the problem and reopen the file, write down the data and try to close again. Don't do anything automatically in a loop or otherwise. Errors in close are beyond your control in an application.

这篇关于处理的C只读文件关闭错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！