C++如何获取硬盘分区的详细挂载点与剩余空间 _ filesystem库实战【实战】

在C++开发中，尤其是涉及系统工具或监控应用时，获取磁盘分区的详细挂载点与剩余空间是一个常见需求。C++17/20标准库中的std::filesystem为此提供了space函数，但很多开发者初次使用时都会遇到一个困惑：为什么它返回的总是根目录的信息，而不是我想要的特定分区数据？

用 std::filesystem::space 获取分区剩余空间时，为什么总是返回根目录信息？

问题的根源在于对std::filesystem::space作用域的理解偏差。这个函数接收一个路径参数，但它并不负责识别“挂载点”。它的工作机制是：从你给定的路径开始，沿着目录树向上回溯，直到找到该路径所属文件系统的根目录（也就是实际的挂载点），然后返回这个挂载点所在磁盘分区的空间信息。

举个例子，如果你传入“./”或“/home/user”，它返回的其实是/或/home所在那个文件系统的数据。关键在于，你只知道结果属于某个文件系统，却无法直接得知这个文件系统具体挂载在哪个路径上。

所以，正确的解决思路需要分两步走：首先，通过系统接口找出目标路径对应的确切挂载点；然后，再对这个挂载点路径调用space函数。遗憾的是，C++20标准库本身并未提供枚举挂载点的功能，我们必须依赖平台特定的API：

• 在Linux下，通常读取/proc/mounts文件或调用getmntent()函数（需要包含）。
• 在macOS或BSD系统上，则使用getfsstat()函数（需要）。
• Windows平台则需调用GetVolumeInformationByHandleW()配合FindFirstVolumeW()等系列函数。

Linux 下如何用 getmntent 枚举所有挂载点并匹配路径？

核心逻辑很清晰：遍历系统所有的挂载点信息，然后判断你的目标路径是否位于某个挂载点的子树下。这里有个常见的陷阱——不能简单地使用字符串前缀匹配。比如，路径/mnt/data和挂载点/mnt/data2，用前缀判断就会出错。

更可靠的方法是使用std::filesystem::equivalent判断是否就是挂载点本身，或者用自定义的is_subdirectory函数（标准库未直接提供，需自行实现）判断是否为子目录。一段典型的关键逻辑示例如下：

FILE* fp = setmntent(“/proc/mounts”, “r”);
struct mntent* ent;
while ((ent = getmntent(fp)) != nullptr) {
    std::filesystem::path mountpoint(ent->mnt_dir);
    try {
        if (std::filesystem::equivalent(target_path, mountpoint) ||
            std::filesystem::is_subdirectory(target_path, mountpoint)) {
            auto space_info = std::filesystem::space(mountpoint);
            // space_info.capacity, .free, .a vailable
        }
    } catch (...) { /* 权限不足或路径不可访问 */ }
}
endmntent(fp);

在实现时，有几点需要特别注意：

• 务必使用基于文件系统等效性的判断，而非字符串操作。
• /proc/mounts包含了tmpfs、devtmpfs等虚拟文件系统，通常需要根据ent->mnt_type过滤，只保留如“ext4”、“xfs”、“btrfs”等物理磁盘文件系统。
• 对于/proc、/sys这类特殊挂载点调用space()可能会抛出std::filesystem::filesystem_error异常，务必做好捕获和处理。

std::filesystem::space 返回的 free 和 a vailable 有什么区别？

这是另一个容易混淆的概念。简单来说：

• free：指的是磁盘上物理未分配的、空闲的总字节数。
• a vailable：指的是当前用户（或进程的有效UID）实际可写入的字节数。

两者的区别在于，a vailable从free中扣除了许多“不可用”的部分，例如ext系列文件系统为root保留的默认5%空间、用户配额限制、以及可能的overcommit保护预留空间。

这意味着，在做磁盘空间监控告警时，应该优先参考a vailable的值。如果只看free，可能会产生误判——例如在一个ext4分区上，当free空间还剩总容量的5%时，普通用户可能就已经无法写入任何文件了，因为那5%是保留给root的。a vailable总是小于或等于free，在ext4上，其差值大致就是那5%的保留块。当然，像XFS这样的文件系统默认不设保留块，两者数值就会相等。

跨平台封装时，为什么不要试图用 std::filesystem::canonical 推导挂载点？

有些开发者会想，既然std::filesystem::canonical可以解析符号链接得到绝对路径，是否可以用来辅助定位挂载点？答案是：不行。

canonical的作用仅限于解析符号链接和规范化相对路径，它完全“感知”不到文件系统的边界。例如，/home是一个独立挂载的分区，那么canonical(“/home/user”)返回的依然是/home/user，而不是/home。它无法揭示底层的挂载拓扑结构。

因此，真正健壮的跨平台策略必须是“分而治之”：

• 在Linux上，坚持使用getmntent配合equivalent进行路径匹配。
• 在macOS上，使用getfsstat(NULL, 0, MNT_NOWAIT)获取挂载点数量，然后分配缓冲区再次调用以获取详情，遍历struct statfs中的f_mntonname字段。
• 在Windows上，流程稍复杂：先用FindFirstVolumeW枚举所有卷的GUID，然后对每个卷调用GetVolumePathNamesForVolumeNameW来获取其挂载路径（可能是驱动器号如C:\，也可能是NTFS挂载点如D:\Mount\Data）。

最后，别忘了现实世界的复杂性。权限检查和异常处理绝不能省略——在容器环境中，/proc/mounts可能不可读；在Windows上，某些卷可能没有访问权限，这些都会导致space()调用失败。此外，还要考虑一个路径可能对应多个绑定挂载（bind mount），或者存在嵌套挂载点（如/mnt/disk1和/mnt/disk1/sub）的情况。在处理这类场景时，通常的规则是选择最长匹配的那个挂载点路径。