Other Software > Developer's Corner

StCroixSkipper's NTFS USN Journal Explorer

<< < (2/2)

mouser:
Very cool.

StCroixSkipper:
I've made several changes this last week. First, I did a bad thing calling long running functions in the UI thread. So I've put these long running functions, the ones that collect all the files, folders and USN Journal Entries, in a separate thread. Now you no longer get the "Application not responding" message.

I've also added an event handler for double clicking on the results listbox. If you double click on an entry in the results listbox and it happens to be a file that exists, it will call the Process.Start() function and launch the file in the 'associated' application if an association exists for the file type.

I've attached the code and executable.

f0dder:
Just wanted to give a nod of approval - USN journal parsing is definitely something a lot of programs could benefit from, especially backup programs that don't run continuously. An app like SpiderOak, for instance, takes ~10 minutes to scan my source/docs partition for changes when I launch it; if it parsed the USN journal, it'd probably be less than a minute.

And the API that deals with USN are, per Microsoft tradition, pretty... raw. Haven't looked at how you've wrapped it, but just the fact that you're doing this work is appreciated.

A thing to keep in mind when working with the USN journal is that it's of limited size - so, theoretically, you risk missing updates if there's "a long timespan" beetween launches of your application. I've got no clue how long this takes for a normal-traffic volume, though, but you'll need to fallback to regular file-traversing code if you want to be entirely safe. Also, while MFT scanning is fast & nice, you should have a graceful fallback to regular traversal (to support non-admin mode, as well as handling possible future NTFS versions).

At any rate, here's a :Thmbsup: from me :)

i@mjonny:
Hi!

This is pretty impressive stuff  :Thmbsup:

I thought I had disabled ntfslastaccess, apparently not (on this build).

Do you know if that has any impact on what is logged in the journal?

I'm specifically interested in the log (including @ least filename of setup.exe's, for example, ideally with full path in log if possible) of files that have been executed by the user...

Does the USN journal record this level of info?

Thanks

mfcarval:
Hi Dear StCroixSkipper:)

You do a Gr8 job, really amazing.

I have one question.

The Path always Show Unavailable. I check the public  GetPathFromFileReference(UInt64 frn, out string path) function that have Win32Api.NtCreateFile returns NTSTATUS ERROR: "0xc000000d - Parameter Error" .

I Check parameters and I didn't  find any issues. What's Wrong? Could you Check?

kind regards
Marcelo Carvalho

Navigation

[0] Message Index

[*] Previous page