open() 函数参数答案

【问题标题】：open() function parametersopen() 函数参数
【发布时间】：2016-09-29 08:17:49
【问题描述】：

如果您通过考虑最后一个参数“0”来查看下面的代码块，写行是否正常工作？

filename = argv[1];
string = "Example string";
if (stat(argv[1], &buf) != 0)
{
    fd = open(filename, O_WRONLY | O_CREAT, 0);
    if (fd < 0)
    {
        perror(filename);
        exit(1);
    }
    write(fd, string, strlen(string));
    close(fd);
}
else
{
    print("%s file exists\n", filename);
}

【问题讨论】：

你自己试过了吗？
@greydet 不是尝试，而是行为是否被定义，我喜欢这个问题。
@iharob 那么问题不够明确。
最后一个参数pmode 应该是_S_IREAD 或_S_IWRITE 或(_S_IREAD | _S_IWRITE)。
@iharob 这当然是尝试理解行为的第一步，如果这正是你所说的 OP 所希望的。我本来会想到一个问题，例如：“我试过了，得到了 XY 作为输出，或者它失败了。这符合预期吗？”来自 OP。

标签： c posix

【解决方案1】：

来自手册页：

mode 指定在创建新文件时使用的权限。当在标志中指定O_CREAT 时，必须提供此参数；如果未指定 O_CREAT，则忽略 mode。有效权限由进程的umask以通常的方式修改：创建文件的权限为（mode & ~umask）。请注意，此模式仅适用于将来访问新创建的文件； open() 创建只读文件的调用很可能会返回一个读/写文件描述符。

为模式提供了以下符号常量：
S_IRWXU  00700 user (file owner) has read, write and execute permission
S_IRUSR  00400 user has read permission
S_IWUSR  00200 user has write permission
S_IXUSR  00100 user has execute permission
S_IRWXG  00070 group has read, write and execute permission
S_IRGRP  00040 group has read permission
S_IWGRP  00020 group has write permission
S_IXGRP  00010 group has execute permission
S_IRWXO  00007 others have read, write and execute permission
S_IROTH  00004 others have read permission
S_IWOTH  00002 others have write permission
S_IXOTH  00001 others have execute permission

因此，将mode 指定为零，您将创建一个具有0 & ~umask 权限的文件，即没有任何权限的文件。

文件系统对此的确切作用不在open() 或write() 函数的范围内。

【讨论】：

【解决方案2】：

有效，

来自open(2) Linux 手册页

mode 参数指定创建新文件时应用的文件模式位。当在标志中指定O_CREAT 或O_TMPFILE 时，必须提供此参数；如果既没有指定 O_CREAT 也没有指定 O_TMPFILE，则忽略模式。有效模式由进程的 umask 以通常的方式修改：在没有默认 ACL 的情况下，创建文件的模式为 (mode & ~umask)。 请注意，此模式仅适用于以后对新创建文件的访问；创建只读文件的 open() 调用很可能会返回一个读/写文件描述符。

理论上，您对该文件的访问权将一直有效，直到您致电 close()，因为我理解我在上面摘录中突出显示的部分。

【讨论】：

【解决方案3】：

有趣的问题。 POSIX 说：

oflag 参数后面的参数不影响文件是否打开以供读取、写入或两者兼而有之。

这意味着由于您正在处理来自open 的错误返回，如果您到达write 行，则行为已明确定义。

稍微扩展一下为什么会这样。在类 unix 系统上的大多数文件系统上，与文件相关的元数据不应影响已打开的文件描述符。例如，您可以删除已打开的文件。这实际上在临时文件中很常见，因此您无需记住在退出时删除它们。这同样适用于文件的权限甚至所有权。事实上，您可以在打开文件的同时chroot，并且您仍然可以写入它而实际上看不到它。您甚至可以使用文件描述符传递将打开的文件描述符提供给不允许打开该文件的另一个进程。这通常用于权限分离。无论以后更改权限如何，您在创建文件描述符时拥有的权限都是有效的。所以你的问题是一个非常有趣的边缘案例，因为它询问文件的文件系统权限是在我们为其创建文件描述符之前还是之后设置的，而 POSIX 似乎对此很清楚。

我现在只能想到两个例外。首先是当有人强行将文件系统重新挂载为只读时，在这种情况下，内核将通过可怕的体操使您的文件描述符无效，这将导致其所有操作失败。第二个是 AFS，当您关闭文件时（或者，当本地系统上文件的最后一个用户关闭它并将其发送到服务器时）实际检查您的权限，这会导致您的时间受限访问的搞笑问题标记在您打开文件时有效，但在您关闭文件时不再有效。这也是close 返回错误的原因（但这是另一个咆哮）。

这就是我在上面提到错误处理的原因。尽管 POSIX 说它不应该有效果，但我可以看到 AFS 或某些其他文件系统拒绝打开这样的文件。

【讨论】：