是否存在使用 O_APPEND 和 O_RDONLY 的有效情况？

Question

在类 unix 系统上，尝试在文件描述符上调用 write 函数有时会导致错误：

[EBADF]  fildes is not a valid file descriptor open for writing.

这通常是在使用open 和不包括O_WRONLY 或O_RDWR 的标志组合打开文件描述符时。

（见 man 2 open，man 2 write 了解更多信息）

那么问题来了：

在什么情况下有效使用O_APPEND、O_TRUNC、O_CREAT 中的任何一个调用open，而不传递其中一个写入标志？

这特别是因为我最近遇到的一个问题，即仅传递 O_APPEND 标志将成功打开文件，但在 fd 上调用 write 将导致 EBADF 因为我未能传递其他内容比O_RDONLY 和open 通话。

如果标志的组合无效（例如，O_APPEND 没有任何写入标志），我希望open 应该失败并出现一些错误，但事实并非如此。这是有什么原因，还是只是历史 posix 标准的产物？

是否存在O_APPEND + O_RDONLY 是有效组合的情况？

Answer 1

这取决于您所说的“有效”。

AFAICT，POSIX 没有特别提到这种标志组合。但它确实说：

应用程序应指定前五个值之一（文件 访问模式）在oflag的值下面：

• O_EXEC
• O_RDONLY
• O_RDWR
• O_SEARCH
• O_WRONLY

然后

并非所有标志组合都有意义。例如，使用 O_SEARCH | O_CREAT 将成功打开预先存在的目录进行搜索，但如果没有该名称的现有文件，则未指定是否创建常规文件。

我会得出结论，根据 POSIX，单独的 O_APPEND 将属于“未指定”行为（即不要这样做）。

查看这里了解更多信息：http://pubs.opengroup.org/onlinepubs/9699919799/

Answer 2

我想不出在任何情况下传递O_APPEND 和O_RDONLY 会产生与传递O_RDONLY 不同的效果。 SUSv4 seems to imply 至少应该允许。

对于O_TRUNC，SUSv4没有指定传递O_RDONLY时的行为：

在没有O_RDWR 或O_WRONLY 的情况下使用O_TRUNC 的结果是未定义的。

fcntl() 可以在描述符创建后更改状态标志，因此可能看起来像是一种方式，例如O_APPEND 在打开文件 O_RDONLY 时可能很重要。然而，

在 arg 中设置的与文件访问模式和文件创建标志对应的位（如 中定义）应被忽略。如果应用程序更改了 arg 中除此处提及的以外的任何位，则结果未指定

在 Linux 上，fcntl(2) 可以更改 O_APPEND、O_ASYNC、O_DIRECT、O_NOATIME 和 O_NONBLOCK 标志，但这些都不会改变。这个讨论。

有点做作，但我想传递O_RDONLY | O_APPEND 可能会影响你在传递fcntl(fd, F_GETFL, ...) 时返回的标志。不过，我实际上还没有证实这一点。

至于为什么要这样设计，我不知道。