c++如何获取Windows下任意文件的唯一文件标识符【技巧】

C++如何获取Windows下任意文件的唯一文件标识符【技巧】

在Windows系统中，稳定且持久地标识一个文件，推荐使用内核级的FILE_ID，它由VolumeSerialNumber（卷序列号）与FileId（文件ID）共同构成。获取它的标准方法是调用GetFileInformationByHandleEx函数并指定FileIdInfo信息类，同时，打开文件句柄时必须包含FILE_READ_ATTRIBUTES权限和FILE_FLAG_BACKUP_SEMANTICS标志。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

什么是Windows文件的唯一标识符

在Windows操作系统中，若想实现文件的持久追踪与精准识别，仅依赖文件名或路径是不可靠的。一旦文件被重命名或移动到同一磁盘的不同位置，传统标识方式就会失效。此时，真正稳定且不随路径变化的，是操作系统内核提供的FILE_ID（文件标识符）。

该标识符由两个核心部分组成：dwVolumeSerialNumber（磁盘卷序列号）和FileId（一个ULARGE_INTEGER类型的唯一编号）。这里需要澄清一个常见误解：许多开发者习惯使用GetFileInformationByHandle函数返回的nFileIndexHigh和nFileIndexLow作为文件索引。实际上，这只是旧式FAT/NTFS文件系统的索引信息，在ReFS等现代文件系统或处理符号链接时可能失效。当前最可靠、最推荐的方法是使用GetFileInformationByHandleEx函数配合FileIdInfo信息类来获取。

使用GetFileInformationByHandleEx获取FILE_ID

具体如何操作？关键在于两个环节：以正确的权限打开文件句柄，然后请求正确的文件信息。

首先，打开句柄的方式至关重要。所需权限仅为FILE_READ_ATTRIBUTES，无需GENERIC_READ（这意味着即使没有读取文件内容的权限也能获取ID）。但一个极易被忽略的关键点是，必须添加FILE_FLAG_BACKUP_SEMANTICS标志。对于目录文件，缺少此标志必然导致打开失败；对于普通文件，添加此标志有助于绕过某些访问控制列表（ACL）的限制，是提升兼容性的最佳实践。

完整的操作流程可分解为以下步骤：

• 调用CreateFile函数，将dwDesiredAccess参数设置为FILE_READ_ATTRIBUTES，并在dwFlagsAndAttributes参数中包含FILE_FLAG_BACKUP_SEMANTICS。
• 仔细检查返回的句柄是否为INVALID_HANDLE_VALUE，确认有效后，再调用GetFileInformationByHandleEx。
• 调用该函数时，将第三个参数设置为FileIdInfo，系统会将信息填充到FILE_ID_INFO结构体中。请牢记，只有VolumeSerialNumber和FileId的组合，才是能够跨越系统重启、持久稳定的唯一文件标识。

HANDLE h = CreateFile(L"C:\test.txt", FILE_READ_ATTRIBUTES,
                      FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
                      nullptr, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, nullptr);
if (h != INVALID_HANDLE_VALUE) {
    FILE_ID_INFO info = {};
    if (GetFileInformationByHandleEx(h, FileIdInfo, &info, sizeof(info))) {
        // info.VolumeSerialNumber + info.FileId 为唯一标识
    }
    CloseHandle(h);
}

为什么不推荐使用GetFileInformationByHandle的nFileIndex

你可能会疑惑，旧的API也能获取一个文件索引号，为何必须改用新方法？

根本原因在于“持久性”与“通用性”的差异。GetFileInformationByHandle返回的nFileIndex，在NTFS文件系统上确实对应文件的MFT（主文件表）记录索引。但其问题在于，它并非持久不变——例如，执行磁盘碎片整理后，该索引可能发生改变。更重要的是，在ReFS这类新型文件系统上，它基本失效，nFileIndexHigh值通常恒为0。

相比之下，FileIdInfo提供的标识符，是由文件系统驱动本身保证的全局唯一且持久的ID。只要文件未被物理删除，此ID就不会改变。当然，新技术有其适用范围：

• 旧API的nFileIndex在Windows Server 2012 R2及以上版本的ReFS卷上已失去意义。
• 即使在NTFS上，若启用了罕见的“对象ID”功能，nFileIndex也可能被绕过。
• FileIdInfo要求的最低系统版本为Windows 8或Windows Server 2012，这意味着它无法在Windows XP或Windows 7等旧系统上使用。

实际应用中的路径处理与权限注意事项

掌握了核心API后，在实际编程中还需注意几个“边界情况”，以避免常见陷阱。

首先是路径解析问题。当遇到符号链接、挂载点或重解析点时，CreateFile的默认行为是“解引用”，即获取目标文件的ID。若你需要获取链接文件本身的ID，则需在打开时额外添加FILE_FLAG_OPEN_REPARSE_POINT标志。

其次是网络路径的处理。访问UNC网络路径时，必须确保网络驱动器已正确映射，或SMB签名已启用。否则，尝试获取FILE_ID很可能失败，返回空值或ERROR_NOT_SUPPORTED错误。

立即学习“C++免费学习笔记（深入）”；

• 访问远程文件时，若GetFileInformationByHandleEx返回ERROR_NOT_SUPPORTED，则需要准备降级方案，例如回退到GetFileInformationByHandle并结合ftLastWriteTime（最后修改时间）等属性进行辅助判断。
• 操作目录时，FILE_FLAG_BACKUP_SEMANTICS标志是必须的，缺少它将直接导致CreateFile调用失败。
• 在UWP沙盒环境或使用受限令牌的进程中，可能因权限不足而无法获取FileIdInfo，此时应检查GetLastError()是否为ERROR_ACCESS_DENIED。

最后，必须明确FILE_ID的本质：它并非基于文件内容计算得出的哈希值，也不依赖于文件路径。它是文件系统分配的内部元数据标识。只要文件未被删除且未跨磁盘卷移动，此ID就是唯一的。但请注意，切勿将其用作加密或安全凭证——因为它可以被枚举，且本身不具备防篡改特性。