c # — Перечисление NTFS MFT: поддержка FSCTL_ENUM_USN_DATA и USN_RECORD_V3

я использую FSCTL_ENUM_USN_DATA перечислить по MFS NTFS, чтобы я мог создать базу данных каталогов на основе USN_RECORD FileReferenceNumbers. Я создаю эту базу данных, чтобы отслеживать изменения файлов на диске NTFS, используя журнал изменений NTN USN и читая USN_RECORD (используя FileReferenceNumber и ParentFileReferenceNumber, которые ссылаются на базу данных каталога). Увидеть Вот для информации о том, как это сделать.

Моя проблема связана с версиями USN Record. Если вы посмотрите, USN_RECORD_V2 поддерживает другой тип данных для FileReferenceNumbers (DWORDLONG), чем USN_RECORD_V3 (FILE_ID_128). Это было бы хорошо, если бы FSCTL_ENUM_USN_DATA поддерживал USN_RECORD_V3. Проблема в том, что USN_RECORD_V3 используется в Windows 10, а USN_RECORD_V2 — в Windows 7.

FSCTL_ENUM_USN_DATA принимает MFT_ENUM_DATA_V1 или же MFT_ENUM_DATA_V0 в качестве входного буфера. Я предполагал, что V1 поддерживает FILE_ID_128 FileReferenceNumbers, но это предположение оказалось неверным. Кажется, что нет никакой поддержки для USN_RECORD_V3 и связанного с ним типа данных FileReferenceNumber. Таким образом, отслеживание изменений на диске NTFS с использованием журнала изменений NTFS в версиях Windows, использующих USN_RECORD_V3 или более позднюю версию, является огромной проблемой в настоящее время.

Я нашел временное решение! В Windows 10 при перечислении MFT FSCTL_READ_ENUM_DATA возвращал только USN_RECORD_V2, давая FileReferenceNumbers типа DWORDLONG. В свою очередь, я был вынужден сдвинуть биты этих DWORDLONG FileReferenceNumbers в 128-битный буфер, чтобы кэш каталога соответствовал USN_RECORD_V3, возвращенным из FSCTL_READ_USN_JOURNAL вызов.

Однако я не могу не чувствовать, что что-то упустил. У кого-нибудь есть какие-то другие решения этой проблемы или альтернативные подходы, которые можно использовать? Имейте в виду, мониторинг изменений, которые были внесены в диск, когда программа не работала, имеет первостепенное значение для моего проекта.