I'm using FSCTL_ENUM_USN_DATA to enumerate over the NTFS MFT so that I may build a directory database based on USN_RECORD FileReferenceNumbers. I'm constructing this database so that I can monitor file changes on an NTFS drive by using the NTFS USN Change Journal and reading USN_RECORD's (using FileReferenceNumber and ParentFileReferenceNumber, which reference the directory database). See here for info on doing this.
My issue is with the USN Record versions. If you look, USN_RECORD_V2 supports a different datatype for FileReferenceNumbers (DWORDLONG) than USN_RECORD_V3 (FILE_ID_128). This would be fine, if FSCTL_ENUM_USN_DATA supported USN_RECORD_V3. The issue is USN_RECORD_V3 is used in Windows 10, while USN_RECORD_V2 is used in Windows 7.
FSCTL_ENUM_USN_DATA takes in a MFT_ENUM_DATA_V1 or MFT_ENUM_DATA_V0 as its input buffer. I assumed V1 supported FILE_ID_128 FileReferenceNumbers, but this assumption turned out to be incorrect. There seems to be no support for USN_RECORD_V3 and its associated FileReferenceNumber data type. Thus, monitoring changes on an NTFS drive using the NTFS Change Journal on versions of windows that use USN_RECORD_V3 or later is a huge issue right now.
I have found a temporary solution! On Windows 10 when enumerating the MFT, FSCTL_READ_ENUM_DATA only returned USN_RECORD_V2's, giving FileReferenceNumbers of type DWORDLONG. In turn, I was forced to bitshift these DWORDLONG FileReferenceNumbers into a 128 bit buffer so that the directory cache would match the USN_RECORD_V3s returned from the FSCTL_READ_USN_JOURNAL call.
However, I can't help but feel that I'm missing something. Does anyone have any other solutions to this problem, or any alternate approaches that can be taken? Keep in mind, monitoring changes that were made to the drive while the program wasn't running is paramount for my project.
