Question

If a close(2) system call fails with EIO, will the file descriptor still be deleted?

If yes, is it not possible to handle a spurious IO error by retrying later? If no, how should one prevent a file descriptor leak?

Answer 1

That’s a tricky question. However, the POSIX standard does cover it in the description of close():

If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is unspecified. If an I/O error occurred while reading from or writing to the file system during close(), it may return -1 with errno set to [EIO]; if this error is returned, the state of fildes is unspecified.

So, the state of the file descriptor is unspecified by the standard.

For most practical purposes, it is closed; there is precious little you can do with the file descriptor even if it is officially open. You could try an innocuous operation (like fcntl() and F_GETFL) and see whether you get EBADF back, indicating the descriptor is formally closed. But if it is open and the cause of the EIO error is permanent, then you’re likely to get EIO every time you try to do anything with it (possibly including the fcntl() call). You might or might not ever get the same descriptor returned by another open-like operation. It is not clear that even dup2() could be successful specifying the ‘dead’ file descriptor as the target if the dead file descriptor is open but uncloseable.