NTFS Documentation

Everything is a file in NTFS. The index to these files is the Master File Table (MFT). The MFT lists the Boot Sector file ($Boot), located at the beginning of the disk. $Boot also lists where to find the MFT. The MFT also lists itself.

Located in the centre of the disk, we find some more Metadata files. The interesting ones are: $MFTMirr and $LogFile. The MFT Mirror is an exact copy of the first 4 records of the MFT. If the MFT is damaged, then the volume could be recovered by finding the mirror. The LogFile is journal of all the events waiting to be written to disk. If the machine crashes, then the LogFile is used to return the disk to a sensible state.

Hidden at the end of the volume, is a copy of the boot sector (cluster 0). The only Metadata file that makes reference to it is $Bitmap, and that only says that the cluster is in use.

To prevent the MFT becoming fragmented, Windows maintains a buffer around it. No new files will be created in this buffer region until the other disk space is used up. The buffer size is configurable and can be 12.5%, 25%, 37.5% or 50% of the disk. Each time the rest of the disk becomes full, the buffer size is halved.

    MFT Zone Reservation IS NOT STORED ON DISK
    MFT Zone (reserved space for MFT)
      1 = 12.5%
      2 = 25.0%
      3 = 37.5%
      4 = 50.0%
      Where is this stored on disk?
      volume?  mft?  boot?
      This is the 'system files' space at
      the beginning of the disk.
      NtfsMftZoneReservation

    link in to mft and bitmap
                                

$PROPERTY_SET, $SYMBOLIC_LINK and $VOLUME_VERSION existed in NTFS v1.2, but weren't used. They no longer exist in NTFS v3.0 (that used by Win2K).

Each MFT record has a Standard Header, followed by a list of attributes (in order of ascending Attribute Id) and an end marker. The end marker is just four bytes: 0xFFFFFFFF.

Also called attributes in DOS terminology.

If a NTFS volume is upgraded from v1.2 to v3.0, then this attribute won't be upgraded (lengthened) until it is accesssed.

Are the Version fields and the Class Id ever used?

It can be either resident or non-resident. This attribute has a no minimum or maximum size.

The offset at 0x07 is just one byte long, unusual for an attribute.

If this attribute is non-resident, then the data runs must fit into one MFT record.

The $ATTRIBUTE_LIST may be needed if the file:

    8 VCN lowest_vcn;
    Lowest virtual cluster number of this portion of the attribute value. This is usually 0. It
    is non-zero for the case where one attribute does not fit into one mft record and thus
    several mft records are allocated to hold this attribute. In the latter case, each mft
    record holds one extent of the attribute and there is one attribute list entry for each
    extent. NOTE: This is DEFINITELY a signed value! The windows driver uses cmp, followed
    by jg when comparing this, thus it treats it as signed.

    24 __u16 instance;
    If lowest_vcn = 0, the instance of the attribute being referenced; otherwise 0.

    The attribute list is used in case where a file need extension FILE records in the
    MFT to be fully described, in order to find any file attribute of this file.
    This file attribute may be non-resident because its stream is likely to grow.

    The extents of one non-resident attribute (if present) immediately follow
    after the initial extent. They are ordered by lowest_vcn and have their instance set to zero.
                                

This is a File Reference to the base record of the parent directory.

The allocated size of a file is the amount of disk space the file is taking up. It will be a multiple of the cluster size. The real size of the file is the size of the unnamed data attribute. This is the number that will appear in a directory listing.

N.B. The Real Size is only present if the Starting VCN is zero. See the Standard Attribute Header for more information.

NTFS implements POSIX-style Hard Links by creating a file with several Filename Attributes. Each Filename Attribute has its own details and parent. When a Hard Linked file is deleted, its filename is removed from the MFT Record. When the last link is removed, then the file is really deleted.

N.B. All fields, except the parent directory, are only updated when the filename is changed. Until then, they just become out of date. $STANDARD_INFORMATION Attribute, however, will always be kept up-to-date.

N.B. If the file has EAs (Extended Attributes), then the EA Field will contain the size of buffer needed.

N.B. If the file is a Reparse Point, then the Reparse Field will give its type.

Birth Volume Id is the Object Id of the Volume on which the Object Id was allocated. It never changes.

Birth Object Id is the first Object Id that was ever assigned to this MFT Record. I.e. If the Object Id is changed for some reason, this field will reflect the original value of the Object Id.

Domain Id is currently unused but it is intended to be used in a network environment where the local machine is part of a Windows 2000 Domain. This may be used in a Windows 2000 Advanced Server managed domain.

This Attribute may be just 16 bytes long (the size of one GUID).

Even if the Birth Volume, Birth Object and Domain Ids are not used, they may be present, but one or more may be zero.

Need examples where all the fields are used.

(a) 0x1 for now

(b) Usually 0x4 (DACL Present), or 0x14 (DACL Present + SACL Present). See Flags below.

(c) This refers to the Auditing ACL

(d) This refers to the Permissions ACL

The currently implemented (in NT) Types are:

Flags is a bit field. The possible values of Flags depend on the value of Type. When applied to a directory, Access Allowed or Access Denied can have flags of

If the Type is System Audit, then the flags can be

The Access Mask / Rights is a bit field enumerating all the (dis)allowed actions.

When the Dirty Flag is set, Windows NT must perform the chkdsk/F command on the volume when it next boots.

A Volume's Serial Number is stored in $Boot.

Usually, a directory has no Data Attribute, and the Data Attribute of a file has no name.

    must have (at least empty) unnamed data attr
                                

NTFS has an advantage: as you can have several data attributes for a file, you can easily implement HFS whose files are made of two parts (also called forks in the HFS terminology): a resource part and a data part. For the data part, you use default unnamed data attribute, and for the resource part, you use a data attribute named e.g. 'resource'.

    link up below
                        

    silly to have a flag of 0x00, remove
                                

The large index flag indicates whether the file attributes index allocation and bitmap are present (when the index is small enough to be stored completely in the root node, these two file attributes are missing).

As defined in $AttrDef, this attribute has a no minimum or maximum size.

This is a sequence of index entries that has a variable length. The sequence is terminated with a special index entry whose last entry flag is set.

    This is the header for indexes, describing the INDEX_ENTRY records, which
    follow the INDEX_HEADER. Together the index header and the index entries
    make up a complete index.

    This is followed by a sequence of index entries (INDEX_ENTRY structures)
    as described by the index header.

    When a directory is small enough to fit inside the index root then this
    is the only attribute describing the directory. When the directory is too
    large to fit in the index root, on the other hand, two aditional attributes
    are present: an index allocation attribute, containing sub-nodes of the B+
    directory tree (see below), and a bitmap attribute, describing which virtual
    cluster numbers (vcns) in the index allocation attribute are in use by an
    index block.

    NOTE: The root directory (FILE_$root) contains an entry for itself.

    struct {
            ATTR_TYPES type;
            Type of the indexed attribute. Is $FILENAME for directories, zero
            for view indexes. No other values allowed.
            COLLATION_RULES collation_rule;        Collation rule used to sort the
            index entries. If type is $FILENAME, this must be COLLATION_FILENAME.

            __u32 bytes_per_index_block;
            Byte size of each index block (in the index allocation attribute).

            __u8 clusters_per_index_block;
            Cluster size of each index block (in the index allocation attribute), when
            an index block is >= than a cluster, otherwise this will be the log of
            the size (like how the encoding of the mft record size and the index
            record size found in the boot sector work). Has to be a power of 2.
    }  INDEX_ROOT;
                                

    split into two tables, at least
                                

The last entry flag is used to indicate the end of a sequence of index entries. Although it does not represent a valid file, it can point to a sub-node.

A copy of the field at offset 10 in the header part of the resident file attribute indexed by the index entry. But why the hell haven't these 2 fields the same size?

A copy of the stream of the resident file attribute indexed by the index entry (e.g. for a directory, the file name attribute).

    Always non-resident (doesn't make sense to be resident anyway!).

    This is an array of index blocks. Each index block starts with an
    INDEX_BLOCK structure containing an index header, followed by a sequence of
    index entries (INDEX_ENTRY structures), as described by the INDEX_HEADER.

    When creating the index block, we place the update sequence array at this
    offset, i.e. before we start with the index entries. This also makes sense,
    otherwise we could run into problems with the update sequence array
    containing in itself the last two bytes of a sector which would mean that
    multi sector transfer protection wouldn't work. As you can't protect data
    by overwriting it since you then can't get it back...
    When reading use the data from the ntfs record header.
                                

(a) The structure of the Reparse Data depends on the Reparse Type. There are
    three defined Reparse Data (SymLinks, VolLinks and RSS) + the Generic Reparse. 

These are just the predefined reparse flags

    The reparse point tag defines the type of the reparse point. It also
    includes several flags, which further describe the reparse point.

    The reparse point tag is an unsigned 32-bit value divided in three parts:

    1. The least significant 16 bits (i.e. bits 0 to 15) specifiy the type of
       the reparse point.
    2. The 13 bits after this (i.e. bits 16 to 28) are reserved for future use.
    3. The most significant three bits are flags describing the reparse point.
       They are defined as follows:
         bit 29: Name surrogate bit. If set, the filename is an alias for
                 another object in the system.
         bit 30: High-latecny bit. If set, accessing the first byte of data will
                 be slow. (E.g. the data is stored on a tape drive.)
         bit 31: Microsoft bit. If set, the tag is owned by Microsoft. User
                 defined tags have to use zero here.

    The system file FILE_$Extend/$Reparse contains an index named $R listing
    all reparse points on the volume. The index entry keys are as defined
    below. Note, that there is no index data associated with the index entries.

    The index entries are sorted by the index key file_id. The collation rule is
    COLLATION_NTOFS_ULONGS. FIXME: Verify whether the reparse_tag is not the
    primary key / is not a key at all. (AIA)
                                

What is the role and the layout of the stream of this file attribute? It could be valuable to have a look at HPFS documentation.

Is it true that the EA name is not unicode?

Information needed

    Operations on this attribute are logged to the journal ($LogFile) like
    normal metadata changes.

    Used by the Encrypting File System (EFS). All encrypted files have this
    attribute with the name $EFS.

    Can be anything the creator chooses.
    EFS uses it as follows:
    FIXME: Type this info, verifying it along the way. (AIA)
                                

On a freshly formatted volume, inodes 0x0B to 0x0F are marked as in use, but empty. Inodes 0x10 to 0x17 are marked as free and not used. This doesn't change until the volume is under a lot of stress.

When the $MFT becomes very fragmented it won't fit into one FILE Record and an extension record is needed. If a new record was simply allocated at the end of the $MFT then we encounter a problem. The $DATA Attribute describing the location of the new record is in the new record.

The new records are therefore allocated from inode 0x0F, onwards. The $MFT is always a minimum of 16 FILE Records long, therefore always exists. After inodes 0x0F to 0x17 are used up, higher, unreserved, inodes are used.

This effect may not be limited to the $MFT, but more evidence is needed.

For some reason $ObjId, $Quota, $Reparse and $UsnJrnl don't have inode numbers below 24, like the rest of the Metadata files.

Also, the sequence number for each of the system files is always equal to their mft record number and it is never modified.

The description of each file is packed into FILE records.

If one record is not large enough (this is unusual), then an $ATTRIBUTE_LIST attribute is needed.

The first 24 FILE records are reserved for the system files. For a full list see the Files page.

To prevent the MFT becoming fragmented, Windows maintains a buffer around it. No new files will be created in this buffer region until the other disk space is used up. The buffer size is configurable and can be 12.5%, 25%, 37.5% or 50% of the disk. Each time the rest of the disk becomes full, the buffer size is halved.

The MFT is self-referencing.

The MFT has some space reserved for future expansion. MFT records 12 - 15 are marked as in use, but are empty. MFT records 16 - 23 are marked as not in use, however they are never used.

Under Windows, the MFT cannot shrink whilst the system is running.

A copy of at least the first four FILE records of the $MFT.

Little is known about the LogFile's structure.

The logging area consists of a sequence of 4KB log records.

Each logrecord is structured as follows:

  offset(length)   contents
  0(4)             Magic number 'RCRD'
  1E(12)           Fixup
                                

The logrecord supposedly contains a sequence of variable sized records. The structuring of those is not clear. File 2 is $LogFile, which contains transaction records to guarantee data integrity in case of a system failure. As pp. 37 describe, it consists of 2 copies of the restart area, and the 'infinite' logging area.

When you want to write a file on a storage unit, you have to update the file itself plus some tables of the filesystem (say as an example the date of the file). At this point, you need a transaction made of 2 operations (update the file itself, update the date of the file).

If the transaction is realized, you are sure that your file is written on the storage unit, and that the filesystem has been left in a defined state.

If the transaction is not realized (in case of e.g. power failure, or system failure in general), the filesystem is in an undefined state. The only way for you to put it back in a defined (and sane) state (this operation is called a roll-back) is to log in a special file, the log file, which operations of the transaction have been successfully completed.

At the first access to the disk after a system failure, the system read the log file and rolls back all the operations to the beginning of the last transaction.

Log file organization:

Two restart areas present in the first two pages (restart pages). When the volume is unmounted they should be identical.

These are followed by log records organized in pages headed by a record header going up to log file size.

Not all pages contain log records when a volume is first formatted, but as the volume ages, all records will be used.

When the log file fills up, the records at the beginning are purged (by modifying the oldest_lsn to a higher value presumably) and writing begins at the beginning of the file. Effectively, the log file is viewed as a circular entity.

Log file restart page header (begins the restart area):

  struct {
    NTFS_RECORD;              The magic is "RSTR".
    __u64 chkdsk_lsn;         The check disk log file sequence 
                              number for this restart page. 
                              Only used when the magic is changed 
                              to "CHKD". = 0
    __u32 system_page_size;   Byte size of system pages, has to be
                                        >= 512 and a power of 2. Use this
                              to calculate the required size of the
                              usa and add this to the
                              ntfs.usa_offset value. Then verify
                              that the result is less than the 
                              value of the restart_offset. = 0x1000
    __u32 log_page_size;      Byte size of log file records, 
                              has to be >= 512 and a power of 2.
                              = 0x1000
    __u16 restart_offset;     Byte offset from the start of the
                              record to the restart record. 
                              Value has to be aligned to 8-byte
                              boundary. = 0x30
    __s16 minor_ver;          Log file minor version. Only check if
                              major version is 1. (=1 but >=1 is
                              treated the same and <=0 is also
                              ok)
    __u16 major_ver;          Log file major version (=1 but =0 is
                              ok)
  } RESTART_PAGE_HEADER;
                                

Log file restart area record:

The offset of this record is found by adding the offset of the RESTART_PAGE_HEADER to the restart_offset value found in it.

  struct {
    __u64 current_lsn;        Log file record. = 0x700000, 0x700808
    __u16 log_clients;        Number of log client records 
                              following the restart_area. = 1
    __u16 client_free_list;   How many clients are free(?). If !=
                              0xffff, check that log_clients >
                              client_free_list. = 0xffff
    __u16 client_in_use_list; How many clients are in use(?). 
                              If != 0xffff check that log_clients
                                        > client_in_use_list. = 0
    __u16 flags;              ??? = 0
    __u32 seq_number_bits;    ??? = 0x2c or 0x2d
    __u16 restart_area_length;Length of the restart area. 
                              Following checks required if version
                              matches. Otherwise, skip them.
                              restart_offset + restart_area_length
                              has to be <lt;= system_page_size.
                              Also, restart_area_length has to be
                                        >= client_array_offset +
                              (log_clients * 0xa0). = 0xd0
    __u16 client_array_offset;Offset from the start of this record
                              to the first client record if versions
                              are matched. The offset is otherwise
                              assumed to be (sizeof(RESTART_AREA) +
                              7) & ~7, i.e. rounded up to first
                              8-byte boundary. Either way, the
                              offset to the client array has to be
                              aligned to an 8-byte boundary. Also,
                              restart_offset + offset to the client
                              array have to be <lt;= 510. Also,
                              the offset to the client array +
                              (log_clients * 0xa0) have to be
                                        <lt;= SystemPageSize. = 0x30
    __u64 file_size;          Byte size of the log file. If the
                              restart_offset + the offset of the
                              file_size are > 510 then corruption
                              has occured. This is the very first
                              check when starting with the
                              restart_area as if it fails it means
                              that some of the above values will be
                              corrupted by the multi sector transfer
                              protection! If the structure is
                              deprotected then these checks are
                              futile of course.
                              Calculate the file_size bits and check
                              that seq_number_bits == 0x43 -
                              file_size bits. = 0x400000
    __u32 last_lsn_data_length;??? = 0, 0x40
    __u16 record_length;       Byte size of this record. If the
                               version matches then check that the
                               value of record_length is a multiple
                               of 8, i.e. (record_length + 7) &
                               ~7 == record_length. = 0x30
    __u16 log_page_data_offset;??? = 0x40
  }  RESTART_AREA;
                                

Log file client record:

Starts at 0x58 even though AFAIU the above it should start at 0x60. Something fishy is going on. /-:

  struct {
    __u64 oldest_lsn;          Oldest log file sequence number for
                               this client record. = 0xbd16951d
    __u64 client_restart_lsn;  ??? = 0x700000, 0x700827, 0x700d07
    __u16 prev_client;         ??? = 0x808, 0xd07, 0xd5d
    __u16 next_client;         ??? = 0x70
    __u16 seq_number;          ??? = 0, 4 size uncertain, Regis
                               calls this "volume clear flag" and
                               gives a size of one byte.
    __u16 client_name;         ??? = empty string??? size uncertain
  }  RESTART_CLIENT;
                                

NOTE: Above client record is followed by 0xffffffff probably to indicate the end of the restart area. Then there are 8 bytes = 0, then one __u32 = 8, followed by the Unicode string "NTFS" and then zeroes till the end of the page. Is this important at all?

Log page record page header:

Each log page begins with this header and is followed by several LOG_RECORD structures.

   struct {
      NTFS_RECORD;                        The magic is "RCRD".
      union {
         __u64 last_lsn;
         __u32 file_offset;
      }  copy;
      __u32 flags;
      __u16 page_count;
      __u16 page_position;
      union {
         struct {
            __u64 next_record_offset;
            __u64 last_end_lsn;
         }  packed;
      }  header;
   }  RECORD_PAGE_HEADER;
                                

Possible flags for log records:

   enum {
      LOG_RECORD_MULTI_PAGE = 1,        ???
      LOG_RECORD_SIZE_PLACE_HOLDER = 0xffff,
            This has nothing to do with the log record. 
            It is only so gcc knows to make the flags 16-bit.
   }  LOG_RECORD_FLAGS;
                                

Log record header:

   struct {
      __u64 this_lsn;
      __u64 client_previous_lsn;
      __u64 client_undo_next_lsn;
      __u32 client_data_length;
      struct {
         __u16 seq_number;
         __u16 client_index;
      }  client_id;
      __u32 record_type;
      __u32 transaction_id;
      LOG_RECORD_FLAGS flags;
      __u16 reserved_or_alignment[3];
  *** Now are at ofs 0x30 into struct. ***
      __u16 redo_operation;
      __u16 undo_operation;
      __u16 redo_offset;
      __u16 redo_length;
      __u16 undo_offset;
      __u16 undo_length;
      __u16 target_attribute;
      __u16 lcns_to_follow;             Number of lcn_list entries
                                        following this entry.
      __u16 record_offset;
      __u16 attribute_offset;
      __u32 alignment_or_reserved;
      __u32 target_vcn;
      __u32 alignment_or_reserved1;
      struct {              Only present if lcns_to_follow is not 0.
         __u32 lcn;
         __u32 alignment_or_reserved;
      }  lcn_list[0];
   }  LOG_RECORD;
                                

The restart area (supposedly) has a pointer into the log area, such as the first and last log records written and the last checkpoint record written. If the restart area is screwed, recovery will be very hard - therefore you have two copies of the restart areas.

Individual log records are identified by logical sequence numbers (LSNs). The log area wraps around, but the LSNs don't (at least not anytime soon), so they are used for identifying log records instead of the offset in the log file.

Any modification of meta data (such as updating the time stamp that the file system was opened) will result in log file actions, which in turn result in restart area changes. It might well be that the dirty bit is implicit rather than explicit: The file system is clean if the last log record says that there are no pending transactions.

The $DATA attribute has zero length.

The Serial Number of a volume is stored in $Boot.

This is the only Metadata File that uses the $VOLUME_NAME and $VOLUME_INFORMATION file attributes.

Its layout is a sequence of records. Each record defines one file attribute, and its layout is:

At the moment this is always zero

At the moment this is always zero, but the possible values are:

We've only witnessed three flags: 0x02, 0x40 and 0x80. It seems that 0x40 and 0x80 are never seen together. Therefore, the guess is that:

It should be possible to add user-defined attributes to this file.

$AttrDef has big WAS it? 36K?

yep in nt4 = 36K mostly blank

now 2560 = 15attrs + 1 blank (2.5K)

This Data Stream only exists when there are Reparse Points on the Volume. It consists of repeating groups of:

See the Directory Page for more information.

The lowest bit represents the lowest numbered LCN. Thus:

To prevent the MFT becoming fragmented, Windows maintains a buffer around it. No new files will be created in this buffer region until the other disk space is used up.

The buffer size is configurable and can be 12.5%, 25%, 37.5% or 50% of the disk. Each time the rest of the disk becomes full, the buffer size is halved.

The size of this file is always a multiple of 8 bytes (64 clusters). Because of this rounding-up, the $Bitmap will represent slightly more clusters than the disk has. These bit are always set to 1.

The backup copy of the boot sector lies in this no-mans-land the cluster is hence marked as in use.

In theory, on very small volume, this attribute could be resident. In practice, Windows crashes.

The first 40 bytes are the same as for FAT boot sectors, except that unused fields are zeroed.

Because this file begins with a boot sector, it must start at physical cluster 0 (this is the only cluster that NTFS can not move). This forces the data attribute of this file to be non-resident. Consequently, the copy of the boot sector (critical data) can be located anywhere on the volume.

For crash recovery purposes Windows NT 3.51 saves a copy of the boot sector and puts it in the logical middle of the volume. Windows NT and later put it at the end of the volume.

This is always zero length.

It is a file the size of the volume. Any cluster that is OK, is represented by a sparse (zero) cluster. Any bad cluster points to that cluster on disk.

A cluster is bad if it contains at least one bad sector.

Because this system file works as any other file, all the bad clusters are marked as used in the $Bitmap system file, so they can never ever be used by any other file.

NTFS support hot-fixing: no more FAT's "Abort, Retry, Fail?". If a new bad cluster is found while the system is running, it is silently added to this file. If the cluster was on a fault tolerant volume, ftdisk (the fault tolerant volume driver) reconstitutes the data and NTFS stores them in another free cluster.

This file deals with Clusters not sectors. The Cluster is the smallest unit of disk space that NTFS will use.

The Security Descriptor Stream ($SDS) contains a list of all the Security Descriptors on the volume.

Each entry is padded to a 16 byte boundary and has a hash for indexing purposes.

  sorted by security id
  Self-relative? == has 2 * SID
  generally a large file, not all used
  there may be missing entries - test
  large block of ids at start, then junk, then another block at 256KB
                                

The Security Descriptor Hash ($SDH) Index

  Last padding is always 4 bytes and always appears to be the Unicode string "II".
                                

  The Security Id Index ($SII)
                                

  This file is sorted by the hash.
  The security descriptors are stored in the $SDS data stream.
  surprisingly the offset (64 bit isn't 8 byte aligned)
                                

This file allows the system to compare filenames independently of their code page.

This is an ordinary directory. There is no data stream for this file.

Because there are only up to four files in this directory, there's never any need for an $INDEX_ALLOCATION and a $BITMAP.

The index is called $O. This is an index of Object Ids. It should not be confused with the index of the same name, used by the Metadata File $Quota.

The index, $O, is sorted by GUID (0x13). This Collation Rule is specified in the Index Root.

A file's $OBJECT_ID Attribute has a GUID that can be found in this Index. The Index's data provides an MFT reference back to the file.

Flags?

header & repeating group

  sid may be missing (quota flags = default limit => no SID, just padding)
  padding may not be necessary
  index key - xref to which index?
  change time - date/time
  exceeded time - 10/4/01 (not +5 days)
  in the last (null) entry, the padding at 0x0C = 0x02
                                

The index is called $O. This is an index of Owner Ids. It should not be confused with the index of the same name, used by the Metadata File $ObjId.

A file's Owner Id is stored in the $STANDARD_INFORMATION Attribute. The Owner Id can be looked up in $O, to give a Security Id (SID) or looked up in $Q to provide quota information.

  The $Q index contains one entry for each existing user_id on the
  volume. The index key is the user_id of the user/group owning this
  quota control entry, i.e. the key is the owner_id. The user_id of
  the owner of a file, i.e. the owner_id, is found in the standard
  information attribute. The collation rule for $Q is
  COLLATION_NTOFS_ULONG.

  The $O index contains one entry for each user/group who has been
  assigned a quota on that volume. The index key holds the SID of
  the user_id the entry belongs to, i.e. the owner_id. The collation
  rule for $O is COLLATION_NTOFS_SID.

  The $O index entry data is the user_id of the user corresponding
  to the SID.
  This user_id is used as an index into $Q to find the quota control
  entry associated with the SID.
                                

0xA000003 flags - see $REPARSE_POINT
No data!

More information needed.

repeating group

(a) In version 2.0 of the USN Journal, Microsoft uses a FILETIME 64-bit value to randomize the USN ID. However, future versions might use another way to generate the ID, so it is not safe to assume this to be the time of the journals creation.