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

Так что 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, это то, к чему я должен обратиться?


person csharptest.net    schedule 14.08.2010    source источник


Ответы (2)


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

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

person casablanca    schedule 14.08.2010
comment
Идеально! (не могу поверить, что я этого не нашел) Ack - согласен, что 128-битный идентификатор - это излишество... - person csharptest.net; 14.08.2010
comment
Но будьте осторожны, файловая система ReFS, представленная в Windows Server 2012, использует 128-битные идентификаторы файлов, и идентификатор объекта, который вы получаете здесь, больше не гарантируется уникальным на таких томах! - person Christoph; 10.02.2014

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

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

person Dominik Weber    schedule 23.08.2010
comment
Да, я обнаружил это на собственном горьком опыте, вместо этого пришлось использовать FSCTL_CREATE_OR_GET_OBJECT_ID (для чего требуется токен процесса SeBackup). Проблема с 64-битной версией - та же причина, по которой ее создала MS. Мне нужно отслеживать перемещение файла даже между томами или машинами. - person csharptest.net; 24.08.2010