什么是检查错误上接近的原因（）？ [英] What are the reasons to check for error on close()?

问题描述

注意：标记这是重复前请仔细阅读到最后。虽然这是类似的，什么我的答案寻找范围超出了previous问题是问什么了。

Note: Please read to the end before marking this as duplicate. While it's similar, the scope of what I'm looking for in an answer extends beyond what the previous question was asking for.

Wides $ P $垫的做法，我倾向于同意，往往是治疗关闭纯粹为文件描述符，而不是一个潜在的IO资源，释放函数有意义的失败案例操作。事实上，以问题529 的解决之前，POSIX离开了文件描述符的状态（即无论是还是分配或没有）错误后未指定，因此无法以任何有意义的方式回应可移植性错误。

Widespread practice, which I tend to agree with, tends to be treating close purely as a resource-deallocation function for file descriptors rather than a potential IO operation with meaningful failure cases. And indeed, prior to the resolution of issue 529, POSIX left the state of the file descriptor (i.e. whether it was still allocated or not) unspecified after errors, making it impossible to respond portably to errors in any meaningful way.

然而，许多GNU软件竭尽全力来检查错误从关闭和Linux手册页关闭 要求不这样做，共同但仍然严重的编程错误 。 NFS和配额被列为何种情况下关闭可能会产生一个错误，但没有透露更多细节。

However, a lot of GNU software goes to great lengths to check for errors from close, and the Linux man page for close calls failure to do so "a common but nevertheless serious programming error". NFS and quotas are cited as circumstances under which close might produce an error but does not give details.

什么是下关闭的情况下可能会失败，在现实世界中的系统，今天是他们有关？我知道在特别感兴趣，是否有任何现代系统中关闭失败，任何非NFS，非设备特定节点的原因，并以此为NFS或设备 - 相关故障，在他们可能会看到什么样的条件（如配置）。

What are the situations under which close might fail, on real-world systems, and are they relevant today? I'm particularly interested in knowing whether there are any modern systems where close fails for any non-NFS, non-device-node-specific reasons, and as for NFS or device-related failures, under what conditions (e.g. configurations) they might be seen.

推荐答案

曾几何时（2007年3月24日），埃里克Sosman 有以下的故事来在补偿分享。 lang.c 新闻组：

Once upon a time (24 march, 2007), Eric Sosman had the following tale to share in the comp.lang.c newsgroup:

（首先，让我忏悔一点点善意的谎言：这是不是
  FCLOSE（），其失败也未被发现，但POSIX的close（）
  功能;应用程序的本部分使用POSIX I / O。谎言
  是无害的，但是，因为C I / O设备将有
  失败以完全相同的方式，并且未检测到的失败将
  有同样的后果。我将描述发生了什么
  的C'S I / O方面，以避免纠缠于POSIX太多了。）

(Let me begin by confessing to a little white lie: It wasn't fclose() whose failure went undetected, but the POSIX close() function; this part of the application used POSIX I/O. The lie is harmless, though, because the C I/O facilities would have failed in exactly the same way, and an undetected failure would have had the same consequences. I'll describe what happened in terms of C's I/O to avoid dwelling on POSIX too much.)

的情况是理查德·托宾描述的非常多。
  该应用程序是，加载的文档管理系统
  文档文件到内存中，应用了用户的编辑在 -
  告诉当内存副本，然后写了一切，一个新的文件
  保存编辑。它也保持了一级别的老版
  备份为了安全起见：保存操作写信给一个临时
  文件，然后如果这是成功，删除旧的备份，
  改名为旧文档文件到备份的名称，并改名为
  临时文件的文件。李明博 - >垃圾桶，文档 - >李明博，TMP - >商务部

The situation was very much as Richard Tobin described. The application was a document management system that loaded a document file into memory, applied the user's edits to the in- memory copy, and then wrote everything to a new file when told to save the edits. It also maintained a one-level "old version" backup for safety's sake: the Save operation wrote to a temp file, and then if that was successful it deleted the old backup, renamed the old document file to the backup name, and renamed the temp file to the document. bak -> trash, doc -> bak, tmp -> doc.

写入到临时文件步检查几乎所有的东西。该
  fopen（）函数，很明显，也是所有的fwrite（）s乃至最后的
  fflush（）进行检查错误指示 - 但FCLOSE（）
  不是。而在一个系统上它发生的最后几盘
  块没有实际分配到FCLOSE（） - 在I / O
  系统顶上坐着VMS'低级别文件的访问机器，和
  异步的一点是在安排所固有的。

The write-to-temp-file step checked almost everything. The fopen(), obviously, but also all the fwrite()s and even a final fflush() were checked for error indications -- but the fclose() was not. And on one system it happened that the last few disk blocks weren't actually allocated until fclose() -- the I/O system sat atop VMS' lower-level file access machinery, and a little bit of asynchrony was inherent in the arrangement.

客户的系统启用了磁盘配额，以及
  受害者是直到接近他的极限。他打开一个文档，
  编辑了一会，救了他的工作，迄今为止，并超过他
  配额 - 因为错误没有出现哪去未被发现
  直到选中FCLOSE（）。以为保存成功，
  应用丢弃旧​​的备份，改名为原
  文件成为备份，并改名为截断临时
  文件被新的文件。用户的工作时间稍长
  并保存再次 - 同样的事情，但你会注意到，这一次
  唯一幸存的完整的文件删除了，而无论是
  备份和主文档文件被截断。结果：
  整个文档文件变成垃圾，而不仅仅是最近一次会议
  工作，但身边的一切都消失了之前

The customer's system had disk quotas enabled, and the victim was right up close to his limit. He opened a document, edited for a while, saved his work thus far, and exceeded his quota -- which went undetected because the error didn't appear until the unchecked fclose(). Thinking that the save succeeded, the application discarded the old backup, renamed the original document to become the backup, and renamed the truncated temp file to be the new document. The user worked a little longer and saved again -- same thing, except you'll note that this time the only surviving complete file got deleted, and both the backup and the master document file are truncated. Result: the whole document file became trash, not just the latest session of work but everything that had gone before.

由于墨菲将有它，受害人的老板
  即购买了几百许可证的部门我们
  软件，和我的飞往圣路易斯是特权
  扔在狮子。

As Murphy would have it, the victim was the boss of the department that had purchased several hundred licenses for our software, and I got the privilege of flying to St. Louis to be thrown to the lions.

[...]

在这种情况下，FCLOSE的失败（）将（如果检测到）具有
  停止删除，和重命名序列。用户将已
  告诉嘿，有保存文档的问题;做一些事情
  关于它，然后再试一次。与此同时，一切都没有改变磁盘上。
  即使他一直未能挽救他的最新一批的工作，他会
  至少不是已经失去了才去了一切。

In this case, the failure of fclose() would (if detected) have stopped the delete-and-rename sequence. The user would have been told "Hey, there was a problem saving the document; do something about it and try again. Meanwhile, nothing has changed on disk." Even if he'd been unable to save his latest batch of work, he would at least not have lost everything that went before.

这篇关于什么是检查错误上接近的原因（）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！