I need to get information about where the file is physically located on an NTFS drive. Absolute offset, cluster identifier. I need to scan the disk twice, once to get the selected files, and again I need to open the partition directly in RAW mode and try to find the rest of the data (from deleted files). I need a way to understand that the data I found is the same as the data that I previously processed as a file. When I browse the disk in raw mode, the offset of the data found can be somehow converted to the offset of the file (which has information about the geometry of the drive). Is there any way to do this? Other decisions are being made. Now I am playing with FSCTL_GET_NTFS_FILE_RECORD, but I can not get it to work at the moment, and I'm not sure if this will help.
UPDATE
I found the following function http://msdn.microsoft.com/en-us/library/windows/desktop/aa364952(v=vs.85).aspx It returns a structure containing the variables nFileIndexHigh and nFileIndexLow. Documentation says
The identifier that is stored in the nFileIndexHigh and nFileIndexLow members is called the file ID. Support for file IDs is file system-specific. File IDs are not guaranteed to be unique over time, because file systems are free to reuse them. In some cases, the file ID for a file can change over time.
I really don’t understand what it is. I cannot connect it to the physical location of the file. Is it possible to extract this file identifier from the MFT later?
UPDATE
Found: This identifier and the volume serial number uniquely identify a file. This number can change when the system is restarted or when the file is opened. This identifier and the volume serial number uniquely identify a file. This number can change when the system is restarted or when the file is opened.
This does not meet my requirements, because I am going to open the file, and the fact that the ID may change does not make me happy.
Any ideas?
source share