> From: Duy Nguyen <xxxxxx@gmail.com>
> Date: Sunday, July 21, 2019 6:59 AM

> On Sun, Jul 21, 2019 at 6:45 PM Lassi Kortela <xxxxxx@lassi.io> wrote:

>> "POSIX close(2) is broken", Colin Percival and Taylor Campbell, 2011.
>> <http://www.daemonology.net/blog/2011-12-17-POSIX-close-is-broken.html>

>> Apparently POSIX close() can cause EINTR and leave the file descriptor
>> in an unknown state :D

> At least on Linux EINTR on close() seems impossible [1]. I don't know
> what other POSIX-y OSes do though.

OpenBSD, which aims for correctness as part of its security focus, allows
for EINTR: https://man.openbsd.org/close  Ugh.  My Bionic Beaver close(2)
man page says it can happen if close is interrupted by a signal.  Let's
hear it for New Jersey (https://en.wikipedia.org/wiki/Worse_is_better)!

EIO and the more specific ENOSPC and EDQUOT in Linux are inevitable for
write back caching filesystems, especially ones over a network, and I
don't see any sort of "super-close" as making much sense, real and
unrecoverable at this level errors occurred earlier when you wrote too
much data to a filesystem, the network connection gets dropped between
the write and close, etc.

That does suggest adding a "POSIX Gotchas" section to the SRFI, for this
sort of behavior which we don't expect to be fixed in any future versions
of UNIX like operating systems.  Although that could be limited to
pointing the user to the works of W. Richard Stevens and the like.

And given the complete mess that Linux and today's hardware provide to
users, you can't assume anything about any sort of close or synchronized
write operations in terms of persistence.  Thus my concept of one or
more "Persistence Manager" SRFIs some day, that take that into account
and focus on sane recovery after a hardware or operating system oops.
I'll focus first on log style writing, which can be a very useful
building block for all sorts of levels.

- Harold