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

unix posix

Question

Si una llamada al sistema de cierre (2) falla con EIO, ¿se seguirá eliminando el descriptor del archivo?

En caso afirmativo, ¿no es posible manejar un error de IO falso al intentarlo más tarde? Si no, ¿cómo se debe evitar la filtración de un descriptor de archivos?

Answer 1

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

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

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

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