Si close (2) falla con EIO, ¿se eliminará el descriptor del archivo?

Question

Si una llamada al sistema close (2) falla con EIO, ¿se eliminará el descriptor del archivo?

En caso afirmativo, ¿no es posible manejar un error de IO falso volviendo a intentarlo más tarde? Si no, ¿cómo se debe evitar la fuga de un descriptor de archivo?

Answer 1

Esa es una pregunta difícil. Sin embargo, el estándar POSIX cubrirlo en la descripción de close():

Si close() es interrumpido por una señal que es ser cogido, devolverá -1 con errno establecido en [EINTR] y el estado de los filtros no especificados. Si se produjo un error de E/S al leer o escribir en el sistema de archivos durante close(), puede devolver -1 con errno establecido en [EIO]; si se devuelve este error, el estado de los filtros no se especifica.

Por lo tanto, el estado del descriptor de archivo no está especificado en el estándar.

Para la mayoría de los propósitos prácticos, está cerrado; hay muy poco que puede hacer con el descriptor de archivo, incluso si está oficialmente abierto. Puede intentar una operación inocua (como fcntl() y F_GETFL) y ver si vuelve a obtener EBADF, lo que indica que el descriptor está formalmente cerrado. Pero si está abierto y la causa del error EIO es permanente, entonces es probable que obtenga EIO cada vez que intente hacer algo con él (posiblemente incluyendo la llamada fcntl()). Es posible que nunca obtenga el mismo descriptor devuelto por otra operación de tipo abierto. No está claro que incluso dup2() pueda tener éxito al especificar el descriptor de archivo 'muerto' como el destino si el descriptor de archivo inactivo está abierto pero no se puede cerrar.