The change journal works on all NTFS volumes 3.1 and above this means any NTFS volume on Windows 2000 and above. Enumerating the MFT is good but reading the changes is even better because it makes for a great incremental scan routine.
There is three changes you need to handle to keep the log up to date ( FileCreate, RenameNewName, FileDelete).
When a file is created you can keep a log of that files (FileReferenceNumber) these are unique on the system and never change until the file is deleted. Speaking from an incremental backup point of view we don't really need to know the location of the deleted file but we can use the (FileReferenceNumber) to remove that specific record from our incremental log change because it's unique. This keeps the log up to date. When you need to do a scan you can just scan the items in your log because nothing else has changed.
It should be mentioned that DataOverwrite,DataTruncate should also be used in the checksums to keep up to date information but it really boils down to what you want to keep track of on the system.
The ONLY problem I have with the journal is it requires administrative rights.. This also applies to reading the MFT but the actual journal doesn't need to be active. You can read MFT without an active journal. Set the HighUsn member to UInt64.MaxValue there shouldn't be anything above this range.
The best way to handle MFT and the Change Journal is using them with a service otherwise you will need to elevate but you might miss changes as they get purged so a service seems appropriate. If you search around you won't find much or any information regarding the NTFS journal the only article is Keeping Eye on NTFS which is way back in 2000 I belive as far as any real .NET examples I have yet to see anything published outside of a forum of a few code snippets. I have been working with the change journal off and on way back in VB6 before .NET was as appealing as it is now then converting it to VB.NET but C# code is almost identical.
↧
Reading MFT
↧