In my current project I am leveraging the NTFS Change Journal to determine when file/folder changes occur on an NTFS 5.x volume when my file system driver is OFF. This allows me to quickly update my internal database when the file system driver is turned back ON in order to bring it to a consistent state which accurately reflects what is on the filesystem. My database maintains file reference numbers and parent file reference numbers for each file/folder rather than hard-coding their paths. This keeps things simple so that when a folder is renamed/moved, I don’t have to remedy the paths of all the folder’s descendants in the database. If needed, I construct paths on the fly from the database by walking the parent keys and accumulating the name of each parent. When processing change journal records I call NtCreateFile and NtQueryInformationFile to retrieve the current file system path of changed files/folders using just their file reference numbers. With both the original path (acquired from the database) and the potentially new path (retrieved using NtQueryInformationFile) I am able to determine if and how a file has moved.
This works well; however, my code is relying on being able to retrieve the file reference number of any file/folder on the system all the time without room for error. I don’t like coding around assumptions and want to be confident that the code will not break because of it. I understand that it is possible that a file/folder can be exclusively locked if it was opened using a CreateFile derivative with the dwSharedMode parameter set to zero, stating that the item cannot be shared or opened again until the handle is closed.
A way around this problem is to set the dwDesiredAccess parameter to zero which allows you to query a file/folder for information without actually opening them for explicit read/write access. I have tested this and I can retrieve the file reference number from a file/folder that has been exclusively locked as mentioned above. Am I incorrect in assuming that I will always be able to get a handle to a file in this way to retrieve the file reference number? Do you know of other conditions where this could not work? Do SAN and NAS devices maintain file reference numbers or are there cases where this is not supported like some SAN file system strain.