So NTFS uses a 128-bit Guid to identify files and directories, you can view this information easily enough:
C:\Temp>C:\Windows\System32\fsutil.exe objectid query . Object ID : ab3ffba83c67df118130e0cb4e9d4076 BirthVolume ID : ca38ec6abfe0ca4baa9b54a543fdd84f BirthObjectId ID : ab3ffba83c67df118130e0cb4e9d4076 Domain ID : 00000000000000000000000000000000
So this is obvious enough, but how does one retrieve this information programmatically? Looking at the WinApi for OpenFileById(...) you should be able to get this information. One would expect this to be done in the "Win32 FileID API Library", yet the method there (GetFileInformationByHandleEx) returns a FILE_ID_BOTH_DIR_INFO structure. This structure defines a FileId; however, it is a LARGE_INTEGER (64bit) not the full 128 bit identifier.
I'm guessing one could use WMI for this, is that where I should turn?
A bit of searching took me to DeviceIoControl and there lies the answer to your question: FSCTL_GET_OBJECT_ID returns exactly the same IDs as in your output from fsutil.
Anyhow, the docs for BY_HANDLE_FILE_INFORMATION say that the 64-bit file ID already uniquely identifies a file on a given volume. According to Wikipedia, NTFS only supports a maximum of 2^32 files, so the 128-bit ID seems quite unnecessary.
Also please note that NOT every file does have a GUID. The GUID mechanisim is mostly used for .lnk files in order to keep the association when a the traget is moved. Only $Volume and the targets of link files have these GUIDs. Furthermore you can set them by hand.
Their advantage is that the GUID should not clash between volumes, while the file ID does. the FILE_ID is actually 48 bit of MFT_RECORD_NUMBER and 16 bits of MFT_SEQUENCE_ID
来源：https://stackoverflow.com/questions/3482178/how-do-you-read-the-128-bit-ntfs-file-id-for-a-directory-and-or-file