> it is quite possible that errors on a previous write(2) operation are reported only on the final close() ... Failing to check the return value when closing a file may lead to silent loss of data.

> the behavior that occurs on Linux ... the file descriptor is guaranteed to be closed.

So yeah, it's always closed on linux, but POSIX doesn't guarantee that for EINTR specifically, and there are sometimes meaningful errors.

Here is a better explanation than I could write: https://www.joeshaw.org/dont-defer-close-on-writable-files

In resume, man close(2), gives us the potential errors. This is the output for Ubuntu 20.04 LTS:

    EBADF  fd isn't a valid open file descriptor.
    EINTR  The close() call was interrupted by a signal; see signal(7).
    EIO    An I/O error occurred.
    ENOSPC, EDQUOT
           On  NFS,  these  errors  are  not normally reported against
           the first write which exceeds the available storage space, 
           but instead against a subsequent write(2), fsync(2), or close().

Programs that fork/exec will typically close all their open file descriptors, so if a close fails (like an EINTR) it's possible a child could inherit an open file descriptor for a file that they otherwise wouldn't have access to.

File descriptors are also a finite resource so if you're opening and closing thousands of files you could run out.

Both situations are unlikely, but I'm sure somebody has had their day ruined by these.

If you use NFS or other specific drivers you can probably get more interesting errors.