Как вы читаете 128-битный NTFS FILE_ID для каталога и / или файла?

Question

Так что NTFS использует 128-битный Guid для идентификации файлов и каталогов, вы можете просмотреть эту информацию достаточно легко:

C:\Temp>C:\Windows\System32\fsutil.exe objectid query .
Object ID :        ab3ffba83c67df118130e0cb4e9d4076
BirthVolume ID :   ca38ec6abfe0ca4baa9b54a543fdd84f
BirthObjectId ID : ab3ffba83c67df118130e0cb4e9d4076
Domain ID :        00000000000000000000000000000000

Так что это достаточно очевидно, но как можно получить эту информацию программно? Глядя на WinApi для OpenFileById (...), вы сможете получить эту информацию. Можно было бы ожидать, что это будет сделано в " Win32 FileID API Library ", но метод ( GetFileInformationByHandleEx ) возвращает структуру FILE_ID_BOTH_DIR_INFO . Эта структура определяет FileId; однако это LARGE_INTEGER (64 бита), а не полный 128-битный идентификатор.

Полагаю, для этого можно было бы использовать WMI, вот куда мне обратиться?

Answer 1

Немного поиска привело меня к DeviceIoControl, и там лежит ответ на ваш вопрос: FSCTL_GET_OBJECT_ID возвращает точно такие же идентификаторы, как в вашем выводе из fsutil.

В любом случае, документы для BY_HANDLE_FILE_INFORMATION говорят, что 64-битный идентификатор файла уже однозначно идентифицирует файл на данном томе.Согласно Wikipedia , NTFS поддерживает не более 2 ^ 32 файлов, поэтому 128-битный идентификатор кажется совершенно ненужным.

Answer 2

Также, пожалуйста, помните, что НЕ каждый файл имеет GUID.Механизм GUID в основном используется для файлов .lnk, чтобы сохранить связь при перемещении трагета.Только $ Volume и цели файлов ссылок имеют эти GUID.Более того, вы можете установить их вручную.

Их преимущество в том, что GUID не должен конфликтовать между томами, в то время как идентификатор файла это делает.FILE_ID на самом деле 48 бит MFT_RECORD_NUMBER и 16 бит MFT_SEQUENCE_ID