$INDEX_ALLOCATION (0xA0) - Attribute - NTFS Documentation
Description: NTFS Documentation

Home | Files | Attributes | Concepts | Glossary

# Attribute - $INDEX_ALLOCATION (0xA0)

Previous Next

## Overview

This is the basic component of an index (e.g. a directory). This is the storage location for all sub-nodes of the B+ tree that implements an index (e.g. a directory). This file attribute is always non-resident.

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

        this attribute is never resident -- would use index root instead

## Layout of the Attribute

It is simply a sequence of all index buffers that belong to the index.

Offset | Size | Description
--- | --- | ---
~ | ~ | Standard Attribute Header
0x00 | ... | Data runs

### Index Entry

        split into two tables, at least

Offset | Size | Description
--- | --- | ---
~ | ~ | Standard Attribute Header
The next field is only valid when the last entry flag is not set
0x00 | 8 | File reference
0x08 | 2 | L = Length of the index entry
0x0A | 2 | M = Length of the stream
0x0C | 1 | Flags
The next field is only present when the last entry flag is not set
0x10 | M | Stream
The next field is only present when the sub-node flag is set
L - 8 | 8 | VCN of the sub-node in the index allocation attribute

## Notes

### Length of the stream

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?

### Flags

Flag | Description
--- | ---
0x01 | Index entry points to a sub-node
0x02 | Last index entry in the node

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.

### Stream

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.

Copyright (C) Validate HTML Validate CSS