Does calling handler.Sync(), possibly in a loop until err is not EINTR, help?

CC @ianlancetaylor

This is an interesting case. POSIX does not define what happens if close returns EINTR: the descriptor might be closed, or it might remain open. So we definitely can't loop on EINTR as we usually do. If we looped, and the kernel did close the descriptor, then the next call to close might close a descriptor that had just been opened by some other goroutine. In particular, the Linux kernel does promise to close the file descriptor, so we definitely can't loop on GNU/Linux.

Presumably we see EINTR because most kernels do not treat close as a restartable call, so although since this is a pure Go program the SIGWINCH signal handler will have been installed with the SA_RESTART flag set, the kernel may not restart the close calls when it sees EINTR.

You report that you are sometimes seeing corrupted files on disk, so there really was an error. The close operation really was interrupted by a signal, the system call was not restarted, and EINTR is reporting a real problem. But we definitely can't call close again.

So I don't see any solution. I'm open to suggestions.

I would imagine that you could create the same problem with a pure C program, and would have the same difficulty in how to address it. It seems like a bug in how the mount of the Azure file system handles signals, one with no obvious workaround.

@ianlancetaylor I don't know much of C sorry about that. I'll see if I can build a C program to test it against.

@ianlancetaylor I tried the sample c code it did not yield EINTR error by terminal resizing so I had to write a go script to sent SIGWINCH for the running (C program) PID.

I ran the executable(C exec) multiple times. And the only time it failed it errored with "Input/output error" EIO. I'm not very confident with my C code so I can't probably speak much as to why it did not error with EINTR.

If it helps the go program that was sending SIGWINCH to running C program Pid look somewhat like this

        pid, err := strconv.Atoi(os.Args[1])
	if err != nil {
		panic(err)
	}

	for {
		err = syscall.Kill(pid, syscall.SIGWINCH)
		if err != nil {
			panic(err)
		}
		time.Sleep(10 * time.Millisecond)
	} 

A user-code workaround may be to call f.Sync() before f.Close(). If either of those fails, you should abort.

@networkimprov That could have a possible solution but because of the EINTR error on .Close (even when all data have been flushed) we mounted drive contain a reference to file because of which creating the same file again never succeed.

Just an update I'm also speaking with Azure tech support about this as @ianlancetaylor suggested it could be a bug on the Azure file system on how it handles signals.

Have you tried writing the file at a temporary path, then f.Sync() and rename it? On failure, remove the temporary path if it exists, then start over if the renamed path doesn't exist. See also:

https://danluu.com/file-consistency/
https://danluu.com/deconstruct-files/

@meetme2meat To get equivalent C code the C program needs to use the sigaction function to install a signal handler for SIGWINCH. Without a signal handler you won't get an EINTR error.

At this point I don't see anything that we could change in Go to fix this problem. So I am going to close this issue.

I am definitely open to suggestions if anybody has any ideas, but for now I think this can only be regarded as a bug in the file system implementation, or possibly the kernel.