最可靠的方式是通过statfs获取文件系统类型魔数后，对照已知CoW文件系统列表判断：Linux下检查buf.f_type是否等于BTRFS_SUPER_MAGIC或OVERLAYFS_SUPER_MAGIC，macOS下用strcmp(buf.f_fstypename, "apfs") == 0；但需注意overlayfs仅上层生效、btrfs可能挂载为nodatacow，最终应以ioctl(FS_IOC_CLONERANGE)或clonefile()运行时验证为准。
Linux下用statfs判断是否为btrfs或overlayfs
没有通用API能直接告诉你“这个路径是否启用CoW”，因为CoW是文件系统实现细节，不是POSIX暴露的属性。实际能做的，是通过statfs获取文件系统类型，再结合已知支持CoW的FS列表做判断。主流支持CoW的有btrfs、overlayfs（作为上层）、zfs（但ZFS在Linux上需额外模块，且statfs返回ZFS而非标准值），而ext4默认不开启CoW（即使启用了reflink也需显式调用）。
关键步骤：
- 调用
statfs(path, &buf)，检查buf.f_type - 对照
<linux/magic.h>中定义的魔数：BTRFS_SUPER_MAGIC（0x9123683E）、OVERLAYFS_SUPER_MAGIC（0x794C7630） - 注意：
overlayfs的f_type只在上层目录生效；若路径在lowerdir里，会返回底层FS类型（如ext4），此时不能认为它支持CoW
macOS下无法可靠判断APFS CoW状态
APFS原生支持CoW（如clonefile()、copyfile() with CPF_CLONE），但系统不提供API查询某路径是否启用CoW——它默认全局启用，且不可关闭。所以对macOS而言，只要路径在APFS卷上（可通过statfs查buf.f_fstypename是否为"apfs"），就可认为具备CoW能力。
但要注意两点：
立即学习“C++免费学习笔记（深入）”；
-
statfs返回的f_fstypename在macOS上是字符串，不是魔数，需用strcmp(buf.f_fstypename, "apfs") == 0 - 如果路径挂载自网络FS（如SMB/NFS），或位于Case-sensitive APFS卷，CoW行为可能受限或不生效，但
statfs仍返回"apfs"——这属于误报，只能靠运行时clonefile()失败来兜底
跨平台判断要避开statvfs和fstatfs
statvfs（POSIX标准）不返回文件系统类型，fstatfs（Linux）需要fd而非路径，且部分旧内核不支持所有魔数。统一用statfs最稳妥，但Windows无对应接口——NTFS有类似CoW的稀疏文件和重解析点，但语义不同，不应混为一谈。
实操建议：
- Linux/macOS共用
statfs，但分支处理：#ifdef __linux__比魔数，#ifdef __APPLE__比字符串 - 不要依赖
buf.f_flags & ST_RDONLY判断CoW——只读挂载不影响CoW机制本身 - 避免在容器内直接判断：/proc/mounts可能显示
overlay，但statfs对容器内路径返回的是overlayfs，不是宿主机底层FS
真正要用CoW时必须运行时验证
文件系统类型只是线索，不是保证。比如btrfs可能被挂载为nodatacow，此时chattr +C也不生效；overlayfs的upperdir虽是btrfs，但lowerdir是ext4，写入lowerdir就不会触发CoW。
所以关键操作前，应尝试最小验证：
- Linux：调用
ioctl(fd, FS_IOC_CLONERANGE, &range)，捕获ENOTSUP或EXDEV - macOS：调用
clonefile(src, dst, 0)，检查返回值和errno - 别省略
close()后unlink()测试文件——有些FS在文件打开时才真正分配块，关掉再删才能暴露真实行为
CoW是否生效，最终得看系统调用反馈，而不是路径所属的文件系统名字。
