加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 服务器 > 安全 > 正文

unix – 如果EIO关闭(2)失败,文件描述符是否仍然被删除?

发布时间:2020-12-15 19:10:59 所属栏目:安全 来源:网络整理
导读:如果系统通过EIO关闭(2)系统调用失败,文件描述符是否仍然被删除? 如果是,是否可以通过稍后重试来处理虚假的IO错误?如果没有,应该如何防止文件描述符泄漏? 这是一个棘手的问题。但是,POSIX标准在 close() 的描述中确实如此: If close() is interrupte
如果系统通过EIO关闭(2)系统调用失败,文件描述符是否仍然被删除?

如果是,是否可以通过稍后重试来处理虚假的IO错误?如果没有,应该如何防止文件描述符泄漏?

这是一个棘手的问题。但是,POSIX标准在 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.

所以,文件描述符的状态是未标明的。

对于大多数实际的目的,它是封闭的;即使正式打开文件描述符,您也可以使用文件描述符来做一些宝贵的事情。你可以尝试一个无害的操作(如fcntl()和F_GETFL),看看是否让EBADF返回,表示描述符正式关闭。但是如果它是开放的,并且EIO错误的原因是永久性的,那么每次尝试执行任何操作(可能包括fcntl()调用)时,您都可能会收到EIO。你可能也可能不会得到另一个类似open的操作返回的相同的描述符。不清楚的是,如果死文件描述符是打开但不可封闭的,即使dup2()可以成功指定“死”文件描述符作为目标。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读