[H]ow serious is it, today or at any point in the past three decades?
Typical applications process data. They consume some input, and produce a result. So, there are two general cases where close() may return an error: when closing an input (read-only?) file, and when closing a file that was just generated or modified.
The known situations where close() returns an error are specific to writing/flushing data to permanent storage. In particular, it is common for an operating system to cache data locally, before actually writing to the permanent storage (at close(), fsync(), or fdatasync()); this is very common with remote filesystems, and is the reason why NFS is mentioned on the man page.
I have never encountered an error while closing a read-only input file. All the cases I can think of where it might happen in real life using any of the common filesystems are ones where there is a catastrophic failure, something like kernel data structure corruption. If that happens, I think the close() error cannot be the only sign that something is terribly wrong.
When writing to a file on a remote filesystem, close()-time errors are woefully common, if the local network is prone to glitches or just drops a lot of packets. As an end user, I want my applications to tell me if there was an error when writing to a file. Usually the connection to the remote filesystem is broken altogether, and the fact that writing to a new file failed, is the first indicator to the user.
If you don't check the close() return value, the application will lie to the user. It will indicate (by a lack of an error message if not otherwise), that the file was correctly written, when in fact it wasn't, and the application was told so; the application just ignored the indication. If the user is like me, they'll be very unhappy with the application.
The question is, how important is user data to you? Most current application programmers don't care at all. Basile Starynkevitch (in a comment to the original question) is absolutely right; checking for close() errors is not something most programmers bother to do.
I believe that attitude is reprehensible; cavalier disregard for user data.
It is natural, though, because the users have no clear indication as to which application corrupted their data. In my experience the end users end up blaming the OS, hardware, open source or free software in general, or the local IT support; so, there is no pressure, social or otherwise, for a programmer to care. Because only programmers are aware of details such as this, and most programmers don't care, there is no pressure to change the status quo.
(I know saying the above will make a lot of programmers hate my guts, but at least I'm being honest. The typical response I get for pointing out things such as this is that this is such a rare occurrence, that it would be a waste of resources to check for this. That is likely true.. but I for one am willing to spend more CPU cycles and paying a few percent more to the programmers, if it means my machine actually works more predictably, and tells me if it lost the plot, rather than silently corrupts my data.)
Is there a simple, reproducible example of such silent loss of data?
I know of three approaches:
Use an USB stick, and yank it out after the final write() but before the close().
Unfortunately, most USB sticks have hardware that is not designed to survive that, so you may end up bricking the USB stick.
Depending on the filesystem, your kernel may also panic, because most filesystems are written with the assumption that this will never ever happen.
Set up an NFS server, and simulate intermittent packet drops by using iptables to drop all packets between the NFS server and the client.
The exact scenario depends on the server and client, mount options, and versions used. A test bed should be relatively easy to set up using two or three virtual machines, however.
Use a custom filesystem to simulate a write error at close() time.
Current kernels do not let you force-unmount tmpfs or loopback mounts, only NFS mounts, otherwise this would be easy to simulate by force-unmounting the filesystem after the final write but prior the close(). (Current kernels simply deny the umount if there are open files on that filesystem.)
For application testing, creating a variant of tmpfs that returns an error at close() if the file mode indicates it is desirable (for example, other-writable but not other-readable or other-executable, ie. -??????-w-) would be quite easy, and safe. It would not actually corrupt the data, but it would make it easy to check how the application behaves if the kernel reports (the risk of) data corruption at close time.
