C++如何修改文件权限

Linux/macOS 上改文件权限，得老老实实走 chmod 系统调用，传八进制掩码（比如 0644），还得检查返回值。Windows 那边呢，用 SetFileAttributesA 控制只读这类属性就行。两边的语义根本不对等，跨平台时千万别直接硬映射。

Linux/macOS 下用 chmod 系统调用修改文件权限

在类 Unix 系统上，C++ 本身没有跨平台的权限修改接口，所以得直接调底层系统 API。chmod 是最直接的方式，接受路径和权限掩码两个参数。很多人容易犯的一个错误是直接传十进制数字，比如写 644 而不是 0644。结果权限被解释成八进制以外的值，行为完全出乎意料——chmod("file.txt", 644) 实际等价于 chmod("file.txt", 01204)（八进制），根本不是预期的 rw-r--r--。

• 权限掩码必须用前缀 0 表示八进制：读写执行对应 4/2/1，用户/组/其他三段组合，比如 0600（仅所有者可读写）、0755（所有者全权，组和其他可读+执行）
• 路径必须是绝对路径或相对于当前工作目录的有效路径；相对路径容易因为程序启动位置不同而失败
• 调用后一定要检查返回值：chmod 成功返回 0，失败返回 -1，这时可以查 errno（比如 EACCES 表示无权修改、ENOENT 表示文件不存在）

Windows 下用 SetFileAttributesA 控制基础属性

Windows 没有 Linux 那样的“权限”概念（rwx），只有文件属性（只读、隐藏、系统等）和 ACL（访问控制列表）。对于普通场景，改 FILE_ATTRIBUTE_READONLY 最常用，对应 C++ 里的 SetFileAttributesA。注意：这个函数不能设置 Linux 式的“执行权限”，也无法替代 ACL 操作；如果需要精细控制（比如限制某用户删除），必须用 SetSecurityInfo 系列 API，复杂度会陡增。

• 设为只读：SetFileAttributesA("file.txt", FILE_ATTRIBUTE_READONLY)
• 清除只读：SetFileAttributesA("file.txt", FILE_ATTRIBUTE_NORMAL)
• 失败时返回 0，调用 GetLastError() 获取错误码（比如 ERROR_ACCESS_DENIED）
• 路径支持正斜杠 / 或反斜杠 \，但建议统一用 \\ 或 / 避免转义问题

跨平台封装时别硬套 POSIX 语义

试图用同一套代码在 Windows 上模拟 chmod 0755 的效果，往往适得其反。比如把 0755 直接传给 SetFileAttributesA，会把高位字节当属性掩码，触发未定义行为。

真正可行的做法是分层处理：先判断平台，再映射语义。比如，把 0755 解释为“允许执行”，在 Linux 下调 chmod，在 Windows 则仅移除只读属性（因为 Windows 默认允许执行）；而 0600 这类纯读写控制，在 Windows 只能靠 ACL 实现，不该假装能完成。

• 检测平台推荐用预处理器：#ifdef _WIN32 / #ifdef __linux__
• 不要依赖第三方库（如 Boost.Filesystem）的 permissions 接口来“统一”行为——它在 Windows 上实际调用的仍是 ACL，而且默认不抛异常，失败时静默处理
• 如果项目必须跨平台且需要 ACL 级控制，优先考虑用 icacls（Windows）或 setfacl（Linux）走子进程调用，比手撸 API 更稳

权限修改失败的三个高频原因

权限改不动，90% 不是代码写错，而是环境卡住。

• 当前进程没权限：普通用户无法用 chmod 提升文件属主权限（比如加 suid 位），也不能修改不属于自己的文件（除非是 root）；Windows 下需要管理员提权才能修改系统文件属性
• 文件被占用：Windows 上如果文件正被其他进程打开（尤其记事本、IDE），SetFileAttributesA 会失败；Linux 下虽然允许改权限，但已打开的 fd 仍按旧权限运行
• 文件系统不支持：NTFS 支持 ACL，FAT32 不支持；Linux 挂载的 vfat 或 ntfs-3g 可能忽略 chmod 调用——这时 chmod 返回 0 但实际无效，需要额外验证

调试时先手动用 ls -l 或 attrib 确认原始状态，再看调用前后是否真变了，别只信返回值。