I guess I will close this.

Twitter points out to me that apparently POSIX defines that close can return EINTR, meaning the fd didn't actually get closed and it's up to the caller to repeat the call! But on Linux at least that's not what EINTR means, if it can happen at all. https://lwn.net/Articles/576478/

The comments on that article also suggest that AFS (in particular OpenAFS) is the file system that most often returned errors on close, which makes sense I suppose.

The Linux kernel NFS implementation does set .flush, and the implementation does return errors, so the standard reference to NFS seems accurate.

But I agree that it seems possible to lose those errors if there is a fork.

We could handle this in the syscall package, but is it worth it?

NFS is the best theoretical example, but if you want another you can construct a test around, there are a variety of ways to do this with a TCP socket.

The easiest way I can think of involves a fake network device interfering with packets. It may be possible to do something more portable with SO_LINGER.

We could handle this in the syscall package, but is it worth it?

If the flush implementation returns errors from only the first close, not also from subsequent closes, then even this single-threaded C program will miss the error:

fd = open(name, O_WRONLY|O_CLOEXEC)
if(write(fd) < 0)
	error()
if(fork() == 0) {
	exec()
	exit(1)
}
wait()
if(close(fd) < 0)
	error()

The implicit close during the child's exec will consume the error. Given that a single-threaded C program has the problem, I don't see what we can do in package syscall.

The alternative of course is that all the closes get an error, that fsync returns an error every time you call it, not just the first time. I got lost following the NFS code trying to figure out if that's true.

As far as I can see the NFS code does not save the close/flush value, but I am not certain.

We could fix this in the syscall package as follows: syscall.Close acquires a read lock on a rwmutex across the actual system call. forkAndExecInChild acquires a write lock on the same rwmutex. Thus Close and forkAndExecInChild can not occur simultaneously (and, unfortunately, only one fork can happen at a time). In forkAndExecInChild the parent opens a pipe before the fork (on GNU/Linux this already happens if some SysProcAttr fields are set). After the fork, the parent waits for a response on the pipe. After the fork, the child walks through all the open file descriptors (we've cleverly stored the maximum file descriptor value from syscall.Open, syscall.Pipe, syscall.Socket, etc.). For each file descriptor marked close-on-exec, the child closes it. Any error from close is reported back to the parent on the pipe. When all file descriptors are closed, the child notifies the parent on the pipe that this is complete. The parent saves the errors, indexed by file descriptor; this is safe because the descriptors are, of course, open in the parent. When the parent sees the notification on the pipe, it releases the lock, permitting syscall.Close calls to proceed. When a syscall.Close closes a descriptor, it checks (and clears) the saved error. If the close call succeeded but there is a saved error, syscall.Close returns the saved error.

syscall.Close acquires a read lock on a rwmutex across the actual system call

Things like syscall.Dup2 can also close FDs so they'd need blocking too.