如果你通过考虑最后一个参数“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);
}
答案 0 :(得分:2)
有效,
这是来自open(2)
Linux手册页
mode参数指定在创建新文件时应用的文件模式位。当在flags中指定
O_CREAT
或O_TMPFILE
时,必须提供此参数;如果既未指定O_CREAT
也未指定O_TMPFILE
,则忽略模式。过程的umask以通常的方式修改有效模式:在没有默认ACL的情况下,创建文件的模式为(模式&amp; ~umask < / em>的)。 请注意,此模式仅适用于将来访问新创建的文件;创建只读文件的open()调用可能会返回一个读/写文件描述符。
理论上,在您理解我在上面摘录中突出显示的部分之前,您致电close()
之前,您对该文件的访问权限才有效。
答案 1 :(得分:2)
从联系手册:
mode
指定在创建新文件时使用的权限。在flags中指定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 :(得分:2)
有趣的问题。 POSIX说:
oflag参数后面的参数不会影响文件是否可以读取,写入或同时打开。
这意味着,由于您正在处理来自open
的错误,因此如果您到达write
行,则行为已明确定义。
为了扩展一点,为什么这样做。在类似unix的系统上的大多数文件系统上,与文件相关的元数据不应该影响已经打开的文件描述符。例如,您可以删除已打开的文件。事实上,这对临时文件很常见,因此您无需记住在退出时删除它们。这同样适用于文件的权限甚至所有权。实际上,您可以在保持文件打开的同时chroot
,但仍然可以在不实际看到它的情况下写入文件。您甚至可以使用文件描述符传递将打开的文件描述符提供给另一个不允许打开该文件的进程。这通常用于权限分离。无论以后对权限的更改如何,创建文件描述符时的权限都是有效的。所以你的问题是一个非常有趣的边缘情况,因为它询问文件的文件系统权限是在我们为它创建文件描述符之前或之后设置的,而且POSIX似乎很清楚。
我现在只能想到两个例外。首先是当某人强行将文件系统重新装入只读时,内核将通过可怕的体操来使你的文件描述符无效,这将使其所有操作失败。第二个是AFS,当您关闭文件时(或者当本地系统上的文件的最后一个用户将其关闭并将其发送到服务器时)实际检查您的权限,这会导致您的时间限制访问时出现的滑稽问题打开文件时令牌有效,但关闭它时不再有效。这也是close
返回错误的原因(但这是另一次咆哮)。
这就是为什么我提到上面的错误处理。即使POSIX说它不应该有效,我也可以看到AFS或某些其他文件系统拒绝打开这样的文件。