调用 std::filesystem::status(path) 获取 file_status 后用 .permissions() 提取权限,须先检查路径存在;对符号链接返回链接自身权限,目标权限需用 symlink_status();Windows 仅支持 owner 权限位;权限判断必须用按位与比较,不可直接隐式转换;file_type::unknown 时应放弃权限检查而改用实际 I/O 操作验证。

怎么用 std::filesystem::status() 获取文件权限
直接调用 std::filesystem::status(path) 得到 std::filesystem::file_status,再用 .permissions() 成员函数提取权限位。注意:不能对不存在的路径调用,否则抛 std::filesystem::filesystem_error 异常。
- 必须先检查路径是否存在(
exists(status())或exists(path)),否则会崩溃或异常 -
status()检查的是路径本身的元信息,对符号链接会返回链接文件的权限(不是目标文件);若要获取目标文件权限,用symlink_status() - Windows 下仅支持部分权限位(如
owner_read、owner_write),group和others相关位始终为 false
perms 枚举值和按位判断的实际写法
std::filesystem::perms 是 bitset 风格枚举,所有权限位都是 2 的幂,必须用按位与(&)判断,不能用 ==。
auto p = fs::status("config.txt").permissions();
if ((p & fs::perms::owner_read) == fs::perms::owner_read) {
// 有 owner 读权限
}
if ((p & (fs::perms::owner_read | fs::perms::owner_write)) != fs::perms::none) {
// owner 至少有读或写之一
}
-
fs::perms::none是 0,fs::perms::owner_all是读+写+执行三位组合,不是“全部权限”的语义全集 - 不要写
p & fs::perms::owner_read就完事——它返回非零整数,但 C++ 不保证非零即 true 的隐式转换在所有上下文安全;显式比较更稳妥 - Windows 下
fs::perms::owner_exec始终为 false,即使文件是 .exe;执行权限需靠后缀或系统 API 判断
为什么 fs::status() 有时返回 fs::file_type::unknown
常见于 NFS、某些容器挂载卷、FUSE 文件系统,或权限被严格限制的目录(如 /proc 下的条目)。此时 .permissions() 返回值不可信,且可能为 fs::perms::unknown。
- 遇到
file_type::unknown时,应放弃权限判断,转为尝试 open/read 等实际操作并捕获errno(如EACCES) - 不要假设
fs::status()总能成功——它底层调用stat()或GetFileInformationByHandleEx,失败时抛异常而非静默返回无效值 - 跨平台代码中,建议把权限检查当作“快速预判”,关键逻辑仍以运行时 I/O 错误为准
替代方案:不依赖 的轻量检查
如果项目未启用 C++17 或需兼容旧编译器,可用 POSIX stat()(Linux/macOS)或 Windows API GetFileAttributesEx()。
立即学习“C++免费学习笔记(深入)”;
// Linux 示例 #includestruct stat sb; if (stat("data.bin", &sb) == 0) { bool readable = (sb.st_mode & S_IRUSR) != 0; bool writable = (sb.st_mode & S_IWUSR) != 0; }
- POSIX 的
S_IRUSR等宏与std::filesystem::perms位定义不一致,不可混用 - Windows 上
GetFileAttributesEx()只能区分“只读”标志(对应FILE_ATTRIBUTE_READONLY),无法区分用户/组/其他权限 - 这类方案失去跨平台抽象,但启动快、无异常开销,适合嵌入式或性能敏感场景
perms 值看起来正常,实际 I/O 却失败。










