linux 下应直接读取 /proc/mounts 获取挂载点,因其轻量、可靠、格式固定;windows 下需结合 getlogicaldrives() 与 getdrivetype() 判断真实可用驱动器,跨平台应分设接口避免语义混淆。

Linux 下用 /proc/mounts 解析挂载点最直接
Linux 没有“驱动器盘符”概念,但所有已挂载的文件系统(含磁盘、分区、网络存储等)都记录在 /proc/mounts 中。读取它比调用系统命令更轻量、更可靠,且无需 fork 或解析 shell 输出。
注意:该文件内容与 mount 命令输出基本一致,但格式固定、无颜色/缩进干扰,适合程序解析。
- 每行格式为:
设备名 挂载点 文件系统类型 选项 dump pass,前两项最关键 - 跳过以
none、sysfs、proc、devtmpfs等虚拟文件系统开头的行,它们不是物理磁盘 -
device字段可能是设备路径(如/dev/sda1)、UUID(UUID=...)或 LABEL(LABEL=...),需按需提取真实块设备 - 用
std::ifstream逐行读取,std::string::find_first_of(' ')分割字段更稳妥,避免空格导致的 split 错误
Windows 下必须用 GetLogicalDrives() + GetDriveType()
Windows 的“驱动器”是盘符抽象(C:\、D:\),GetLogicalDrives() 返回一个位掩码,每个 bit 对应 A–Z 盘符是否被定义;但它不区分是否真正挂载或可访问——比如光驱没放盘、网络驱动器断连时,盘符仍存在。
所以必须配合 GetDriveType(L"X:") 过滤出实际可用的本地磁盘、可移动磁盘或固定磁盘(返回值为 DRIVE_FIXED、DRIVE_REMOVABLE 或 DRIVE_FIXED)。
组合式C++代码评审方案,融合静态分析、AI推理、多轮迭代评审和C++专项检查,适用于PR审查、增量代码审查、全项目评审和代码质量评分,触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不要只依赖
GetLogicalDrives()就认为所有 bit=1 的盘符都“已挂载” - 调用
GetDriveType()前必须确保路径末尾有反斜杠(L"C:\"),否则可能返回DRIVE_NO_ROOT_DIR - 对 NTFS 卷,若需获取对应物理设备(如
\.PhysicalDrive0),得进一步查QueryDosDevice或 WMI,这已超出“已挂载”范畴
跨平台封装时别硬套统一接口
试图用同一套 C++ 接口在 Linux 和 Windows 上返回“驱动器列表”,容易引发语义混淆:Linux 返回的是挂载点路径(/home、/mnt/data),Windows 返回的是盘符(C:\)。强行合并成一个 std::vector<:string></:string> 会让调用方难以判断含义。
- 推荐分两个函数:
get_mounted_filesystems()(Linux 风格,返回挂载路径 + 设备)和get_available_drives()(Windows 风格,返回盘符 + 类型) - 若必须统一,返回结构体而非字符串,例如:
struct MountInfo { std::string path; std::string device; std::string fs_type; bool is_physical; }; - 别在 Linux 上尝试模拟盘符逻辑(比如把
/dev/sdb1映射成Z:\)——这既无标准,也破坏用户对路径的预期
常见错误:把 df -h 输出当唯一依据
很多人习惯用 popen("df -h") 解析,但这有几个硬伤:
-
df默认只显示“有空间”的挂载点,tmpfs、devtmpfs等内存文件系统常被过滤掉,而它们确实在/proc/mounts中 - 不同 locale 下单位(G / GB)、小数点符号(. / ,)可能变化,正则解析易崩
- 权限问题:非 root 用户执行
df可能看不到某些挂载(如 NFS),但读/proc/mounts通常没问题 - 性能差:每次调用都要 fork+exec,而
/proc/mounts是内核提供的零拷贝伪文件
除非你明确需要人类可读的空间统计,否则绕过 df 直接读 /proc/mounts 或调用 getmntent() 是更干净的选择。
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!










