When a close() operation on an OS file descriptor is succesful, the record of the FD is set to -1, and on subsequent close() operations the actual call to the OS' close() is not performed.

If an error occurs in the OS' close(), we do not set our record of the FD to -1, so subsequent calls will re-attempt the close().

We should not re-attempt the close().

If the underlying OS library/syscall close() fails, e.g. Stale NFS Handle, then this is a permanent problem. Also, the fd number may be available for reuse by other operations allocating file descriptors.

A customer testcase has demonstrated a FileInputStream.close() throwing an exception due to "Stale NFS Handle", and subsequent calls to close() giving "Bad File Handle".

If the fd is considered closed by the OS, the number could get reused: so it could become valid. We should mark the fd as -1 as soon as close() fails, and not retry the close again - or we risk closing a vaild fd created by some other thread.

[ removed my own comment that we could retry after ENOSPC: this can happen over NFS, but the fd does become invalid after the failed close - we should not retry the close() ]

EINTR is also possible, but we already restart in that case.