> From: "Theo de Raadt" <deraadt@openbsd.org>
> Date: Fri, 07 Aug 2026 09:39:34 -0600
> 
> 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).

And then they made it worse by adding posix_close().