First, you have to have and assert sufficient privileges to access the MFT - this is a pain all by itself. Then, you have to get a handle to a file/folder on the volume - for the calls in the last step...which is to call a Windows API (called DeviceIOControl) in a loop and read the entries from the returned API call - and this is it's own special headache.
Conceptually - this looks like:
static void Main( string[ ] args )
{
if ( Privileges.HasBackupAndRestorePrivileges )
{
using ( var volume = GetVolumeHandle( "C:\" ) )
{
ReadMft( volume );
}
}
}
If you take each of these in turn, asserting sufficient privileges is the most obscure part. There's a Windows API to change the privileges of the running token - and you use that to add the necessary privileges. Here's an excerpt from a class that I use to assert those privileges. You could assert a bunch more privileges - but this should be sufficient for reading the MFT.
Your application will need to run under an account that can actually obtain the requisite privileges - an admin account is good. Also, a backup operator will work.
public static class Privileges
{
private static int asserted = 0;
private static bool hasBackupPrivileges = false;
public static bool HasBackupAndRestorePrivileges
{
get { return AssertPriveleges( ); }
}
/// <remarks>
/// First time this method is called, it attempts to set backup privileges for the current process.
/// Subsequently, it returns the results of that first call.
/// </remarks>
private static bool AssertPriveleges( )
{
bool success = false;
var wasAsserted = Interlocked.CompareExchange( ref asserted, 1, 0 );
if ( wasAsserted == 0 ) // first time here? come on in!
{
success =
AssertPrivelege( NativeMethods.SE_BACKUP_NAME ) &&
AssertPrivelege( NativeMethods.SE_RESTORE_NAME );
hasBackupPrivileges = success;
}
return hasBackupPrivileges;
}
private static bool AssertPrivelege( string privelege )
{
IntPtr token;
var tokenPrivileges = new NativeMethods.TOKEN_PRIVILEGES( );
tokenPrivileges.Privileges = new NativeMethods.LUID_AND_ATTRIBUTES[ 1 ];
var success =
NativeMethods.OpenProcessToken( NativeMethods.GetCurrentProcess( ), NativeMethods.TOKEN_ADJUST_PRIVILEGES, out token )
&&
NativeMethods.LookupPrivilegeValue( null, privelege, out tokenPrivileges.Privileges[ 0 ].Luid );
try
{
if ( success )
{
tokenPrivileges.PrivilegeCount = 1;
tokenPrivileges.Privileges[ 0 ].Attributes = NativeMethods.SE_PRIVILEGE_ENABLED;
success =
NativeMethods.AdjustTokenPrivileges( token, false, ref tokenPrivileges, Marshal.SizeOf( tokenPrivileges ), IntPtr.Zero, IntPtr.Zero )
&&
( Marshal.GetLastWin32Error( ) == 0 );
}
if ( !success )
{
Console.WriteLine( "Could not assert privilege: " + privelege );
}
}
finally
{
NativeMethods.CloseHandle( token );
}
return success;
}
}
Once you're past that hurdle, the rest is - well...still a festival of obscurity. You have to get a handle to a file or folder - with backup semantics. You can more-than-likely just open a FileStream on any old file on the volume you're after and the FileStream will have a handle you can use for subsequent calls. This isn't precisely what my application did - but my app had to do things this answer doesn't have to do.
internal static SafeFileHandle GetVolumeHandle( string pathToVolume, NativeMethods.EFileAccess access = NativeMethods.EFileAccess.AccessSystemSecurity | NativeMethods.EFileAccess.GenericRead | NativeMethods.EFileAccess.ReadControl )
{
var attributes = ( uint ) NativeMethods.EFileAttributes.BackupSemantics;
var handle = NativeMethods.CreateFile( pathToVolume, access, 7U, IntPtr.Zero, ( uint ) NativeMethods.ECreationDisposition.OpenExisting, attributes, IntPtr.Zero );
if ( handle.IsInvalid )
{
throw new IOException( "Bad path" );
}
return handle;
}
For ReadMft - There is a rather complex windows API function - DeviceIOControl - that takes buffers with an epic variety of inputs and returns buffers containing a mind-bending variety of outputs. It's a kind of catch-all API for querying information about various devices - and the volume containing the MFT is a device.
To read the MFT, you call DeviceIOControl with a device IO control code of FSCTL_ENUM_USN_DATA - which returns one USN record for each record in the MFT. There are lots of records per each invocation - and after each invocation, you parameterize the next call in the loop with the first bit of info returned by the previous call.
BTW - I renamed the windows API calls in my code to make them look more .Net-like. I'm not sure I'd do that in the future.
Special note here: You're getting one record for each file - regardless of how many hard links there are - you have to do additional calls to enumerate the hard links.
The file system hierarchy is encoded in the FileReferenceNumber and ParentFileReferenceNumber of the structures you get back from the call. You'd nominally save off these usn records to a list, sorted by FileReferenceNumber and make a secondary index for the ParentFileReferenceNumber - or something like that. For the purpose of illustration, this code just dumps the MFT entries.
This example uses unsafe code - and fixes the location of the buffers containing the input and output. There are different ways to approach this - but this is nice and zippy. If you use this, you have to allow unsafe code in your project settings.
public unsafe static bool ReadMft( SafeHandle volume )
{
var outputBufferSize = 1024 * 1024;
var input = new NativeMethods.MFTEnumDataV0( );
var usnRecord = new NativeMethods.UsnRecordV2( );
var outputBuffer = new byte[ outputBufferSize ];
var okay = true;
var doneReading = false;
try
{
fixed ( byte* pOutput = outputBuffer )
{
input.StartFileReferenceNumber = 0;
input.LowUsn = 0;
input.HighUsn = long.MaxValue;
using ( var stream = new MemoryStream( outputBuffer, true ) )
{
while ( !doneReading )
{
var bytesRead = 0U;
okay = NativeMethods.DeviceIoControl
(
volume.DangerousGetHandle( ),
NativeMethods.DeviceIOControlCode.FsctlEnumUsnData,
( byte* ) &input.StartFileReferenceNumber,
( uint ) Marshal.SizeOf( input ),
pOutput,
( uint ) outputBufferSize,
out bytesRead,
IntPtr.Zero
);
if ( !okay )
{
var error = Marshal.GetLastWin32Error( );
okay = error == NativeMethods.ERROR_HANDLE_EOF;
if ( !okay )
{
Console.WriteLine( "Crap! Windows error " + error.ToString( ) );
break;
}
else
{
doneReading = true;
}
}
input.StartFileReferenceNumber = stream.ReadULong( );
while ( stream.Position < bytesRead )
{
usnRecord.Read( stream );
//-->>>>>>>>>>>>>>>>>
//--> just an example of reading out the record...
Console.WriteLine( "FRN:" + usnRecord.FileReferenceNumber.ToString( ) );
Console.WriteLine( "Parent FRN:" + usnRecord.ParentFileReferenceNumber.ToString( ) );
Console.WriteLine( "File name:" + usnRecord.FileName );
Console.WriteLine( "Attributes: " + ( NativeMethods.EFileAttributes ) usnRecord.FileAttributes );
Console.WriteLine( "Timestamp:" + usnRecord.TimeStamp );
//-->>>>>>>>>>>>>>>>>>>
}
stream.Seek( 0, SeekOrigin.Begin );
}
}
}
}
catch ( Exception ex )
{
Console.Write( ex );
okay = false;
}
return okay;
}
I do something probably kind of cheesy to save myself a lot of work - I add pseudo-serialization methods to windows API structures - so that they can read themselves out of streams. For example, the usnRecord used to read the buffer in the foregoing code is a windows API structure - but with a serialization interface implemented:
[StructLayout( LayoutKind.Sequential )]
internal struct UsnRecordV2: IBinarySerialize
{
public uint RecordLength;
public ushort MajorVersion;
public ushort MinorVersion;
public ulong FileReferenceNumber;
public ulong ParentFileReferenceNumber;
public long Usn;
public long TimeStamp;
public UsnReason Reason;
public uint SourceInfo;
public uint SecurityId;
public uint FileAttributes;
public ushort FileNameLength;
public ushort FileNameOffset;
public string FileName;
/// <remarks>
/// Note how the read advances to the FileNameOffset and reads only FileNameLength bytes.
/// </remarks>
public void Read( Stream stream )
{
var startOfRecord = stream.Position;
RecordLength = stream.ReadUInt( );
MajorVersion = stream.ReadUShort( );
MinorVersion = stream.ReadUShort( );
FileReferenceNumber = stream.ReadULong( );
ParentFileReferenceNumber = stream.ReadULong( );
Usn = stream.ReadLong( );
TimeStamp = stream.ReadLong( );
Reason = ( UsnReason ) stream.ReadUInt( );
SourceInfo = stream.ReadUInt( );
SecurityId = stream.ReadUInt( );
FileAttributes = stream.ReadUInt( );
FileNameLength = stream.ReadUShort( );
FileNameOffset = stream.ReadUShort( );
stream.Position = startOfRecord + FileNameOffset;
FileName = Encoding.Unicode.GetString( stream.ReadBytes( FileNameLength ) );
stream.Position = startOfRecord + RecordLength;
}
/// <summary>We never write instances of this structure</summary>
void IBinarySerialize.Write( Stream stream )
{
throw new NotImplementedException( );
}
}
...where IBinarySerialze is:
public interface IBinarySerialize
{
/// <summary>Reads an object's data from a <see cref="Stream"/></summary>
void Read( Stream stream );
/// <summary>Writes an objects serializable content to a <see cref="Stream"/></summary>
void Write( Stream stream );
}
There are stream extension methods used in this structure. Basically, they're lifted from BinaryReader. Why? Because in .Net 3.5 - where I had to write this originally - the BCL BinaryReader would close the stream you wrapped it around - and I had lots of places where that was just intolerable.
internal static class StreamingExtensions
{
public static ushort ReadUShort( this Stream stream )
{
return BitConverter.ToUInt16( ReadBytes( stream, 2 ), 0 );
}
public static uint ReadUInt( this Stream stream )
{
return BitConverter.ToUInt32( ReadBytes( stream, 4 ), 0 );
}
public static long ReadLong( this Stream stream )
{
return BitConverter.ToInt64( ReadBytes( stream, 8 ), 0 );
}
public static ulong ReadULong( this Stream stream )
{
return BitConverter.ToUInt64( ReadBytes( stream, 8 ), 0 );
}
public static byte[ ] ReadBytes( this Stream stream, int length, bool throwIfIncomplete = false )
