因此,NTFS使用128位Guid来识别文件和目录,您可以轻松地查看此信息:
C:\Temp>C:\Windows\System32\fsutil.exe objectid query . Object ID : ab3ffba83c67df118130e0cb4e9d4076 BirthVolume ID : ca38ec6abfe0ca4baa9b54a543fdd84f BirthObjectId ID : ab3ffba83c67df118130e0cb4e9d4076 Domain ID : 00000000000000000000000000000000
所以这很明显,但是如何以编程方式检索此信息呢?查看OpenFileById(...)的WinApi,您应该能够获得此信息。可以预期这将在“Win32 FileID API Library”中完成,但那里的方法(GetFileInformationByHandleEx)会返回FILE_ID_BOTH_DIR_INFO结构。这个结构定义了一个FileId;但是,它是一个LARGE_INTEGER(64位)而不是完整的128位标识符。
我猜测可以使用WMI,这是我应该转向的地方吗?
答案 0 :(得分:6)
我进行了一些搜索,DeviceIoControl
找到了问题的答案:FSCTL_GET_OBJECT_ID
返回与fsutil
输出完全相同的ID。
无论如何,BY_HANDLE_FILE_INFORMATION的文档说64位文件ID已经唯一标识给定卷上的文件。根据{{3}},NTFS最多只支持2 ^ 32个文件,因此128位ID似乎是不必要的。
答案 1 :(得分:1)
另外请注意,并非每个文件都有GUID。 Th GUID mechanisim主要用于.lnk文件,以便在移动traget时保持关联。只有$ Volume和链接文件的目标具有这些GUID。此外,您可以手动设置它们。
它们的优点是GUID不应该在卷之间发生冲突,而文件ID也是如此。 FILE_ID实际上是MFT_RECORD_NUMBER的48位和MFT_SEQUENCE_ID的16位