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.

Options  StCroixSkipper's USN Journal Explorer v1.2
12 May 2010  3 Comments
Posted by StCroixSkipper 
I've added a button, 'List Files' to allow you to list and display all the files on a volume that match a filter string.

I enumerate through the entire Master File Table to find all the files whose extensions match those in the filter. Why would I want to read the Master File Table rather than enumerating through the disk with Directory.FindFiles()? For an active volume it works about 10 faster.

It works much like 'List Folders'. If you click on a specific file, you'll see a popup window that shows the detail. If you double click on the file name or path in the detail window it calls Process.Start() with the file name to start the application associated with the file extension.

I've also changed the 'Update USN Journal State' from a MessageBox to a Window so I could control where it is placed.

In both 'List Folders' and 'List Files' I've sorted the output before displaying it.

The executable and source files are attached.

I did forget to mention one item.  There is a slight problem with the code. 

The NTFS filesystem writes entries to the USN Journal as changes are made to a volume.  So, if you modify a file in a directory and then delete the directory you'll have first an entry in the journal about the modification, then an entry about the file delete and then an entry about the directory delete.  Since each entry only has the file's 64-bit File Reference Number and the file's parent's 64-bit File Reference Number it is possible to find a journal entry whose parent has been deleted and, hence, does not exist.  I have code to fix this problem but for this little application I haven't added it yet.

p.s.  I have downloaded the executable and source code and I have been able to unpack it and use it.