Martijn Dekker <martijn@inlv.org> wrote:

> Is there any scenario where a file descriptor passed to close(2)
> remains, or might remain, open if EINTR or EIO occurs? The manual page
> does not document this.

It does document it, in the first sentence:

DESCRIPTION
     The close() call deletes a descriptor d from the per-process object
     reference table.

Nothing later on disagrees with this sentence. 

In the kernel, this is sys_close -> fdrelease -> fdremove, and nothing
stops the fd from being removed from the process.

The desciptor is removed first, then other stuff happens.

From fdremove -> fclosef.  That could, in obscure cases return
additional errors from a lower-level (perhaps a filesystem), but such
circumstance do not contradict the firm sentence at the start of the
manual page.  The descriptor was deleted before a condition occurs.

The addition of error return values to close() by POSIX has been
contentious since the start, because it makes this system call operation
non-ACID (even when returning an error, it has performed a step).  This
mainly arrived because of a weird behaviour in NFS.  But many believe the
specification was a mistake, because no program is prepared or capable of
taking corrective action when these errors occur, because sufficient
information about the issue isn't reported AND because the descriptor
which would be needed for resolution has been deleted (see the first sentence).