title: What are the reasons to check for error on close()?
body: <p><strong>Note:</strong> 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.</p>
  
  <p>Widespread practice, which I tend to agree with, tends to be treating <code>close</code> purely as a resource-deallocation function for file descriptors rather than a potential IO operation with meaningful failure cases. And indeed, prior to <a href="http://austingroupbugs.net/view.php?id=529">the resolution of issue 529</a>, 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.</p>
  
  <p>However, a lot of GNU software goes to great lengths to check for errors from <code>close</code>, and the <a href="http://man7.org/linux/man-pages/man2/close.2.html">Linux man page for <code>close</code></a> calls failure to do so "a common but nevertheless serious programming error". NFS and quotas are cited as circumstances under which <code>close</code> might produce an error but does not give details.</p>
  
  <p>What are the situations under which <code>close</code> might fail, on real-world systems, and are they relevant today? I'm particularly interested in knowing whether there are any modern systems where <code>close</code> 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.</p>