doc/attributes.txt

   1 Notes on the storage of attributes.
   2 ===================================
   3
   4 Resident attributes
   5 ===================
   6
   7 Resident attributes are small enough to be stored in the mft record itself.
   8
   9 When an attribute becomes too big to fit in the mft record or when the number
  10 of attributes grows so large that there is no more space in the mft record, the
  11 largest attribute(s) is(are) made non-resident. (Note, that some attributes
  12 cannot be non-resident.)
  13
  14 Non-resident attributes
  15 =======================
  16
  17 Non-resident attributes contain only their non-resident attribute header in the
  18 mft record and the actual attribute value is stored anywhere on the volume
  19 (but not in other mft records).
  20
  21 The value of the attribute is saved as a sequence of clusters, named virtual
  22 clusters, beginning at virtual cluster number (vcn) zero. Each vcn corresponds
  23 to a cluster on the volume, or a logical cluster number (lcn). The lcns on the
  24 volume begin with lcn zero for the very first cluster on the volume.
  25
  26 The location of the attribute value is described by the mapping pairs array
  27 present in the non-resident attribute header structure. The mapping pairs array
  28 contains, in compressed form, the mapping between the attribute's vcns and the
  29 corresponding lcns on the volume.
  30
  31 When the mapping pairs array of a non-resident attribute becomes too large to
  32 fit in the mft record or when there are so many attributes in the mft record
  33 that, even though all attributes that can be non-resident have been made
  34 non-resident, they still do not fit in the mft record, the larger non-resident
  35 attributes are moved away from the mft record to make space.
  36
  37 This is done by moving whole non-resident attribute header structures to other
  38 mft records and/or by splitting the mapping pairs array of attributes into
  39 several non-resident attribute headers, each containing a chunk of the
  40 original mapping pairs array. These non-resident attribute headers each
  41 describing the same attribute value (but different parts of it) are called
  42 extents.
  43
  44 Attribute list attribute
  45 ========================
  46
  47 The attribute list attribute is then added to the base mft record to describe
  48 the location of each attribute.
  49
  50 The attribute list attribute lists all attributes that belong to this mft
  51 record (with the exception of itself). Each entry in the attribute list
  52 describes the attribute listed and in which mft record it's attribute header can
  53 be found. For resident attributes this will be the same number as the base mft
  54 record in which the attribute list attribute is located itself. For non-resident
  55 attributes, this will be another mft record, called an extension mft record.
  56 Naturally, all extension mft records point back to their base mft record.
  57
  58 Only one attribute is stored in an extension mft record, even if the attribute
  59 is very small. At least this is the case with Windows NT4 SP6a driver.
  60
  61 Should the mapping pairs array of an attribute become so large as to not fit
  62 into an extenstion mft record, even though it's attribute is the only attribute
  63 in this extension record, then the attribute is splitt into several extents.
  64 The first extent starts at vcn 0 and has it's lowest vcn value set to zero and
  65 continues up to it's highest vcn value. This is determined by splitting up the
  66 mapping pairs array into chunks which just fit into an extension mft record
  67 each. Thus the first mapping pairs array chunk will determine the value of
  68 the highest vcn for the first extent. The attribute list will contain an entry
  69 for this extent. Then, a second extent is created which has it's lowest vcn
  70 value set to the highest vcn of the previous extent + 1 and the next chunk of
  71 the mapping pairs array is inserted into this extent. Again, an entry for this
  72 extent is placed into the attribute list, and so on, until the whole
  73 non-resident attribute's mapping pairs array has been accomodated.
  74
  75 Should the attribute list become too big to fit inside the base mft record it
  76 is made non-resident. However, it's maximum value size is determined by the
  77 Windows cache manager to be 256kb (the size of a VACB). Also, the mapping pairs
  78 array of the attribute list has to fit inside the base mft record, as an
  79 attribute list can't be described by itself and attribute lists are not allowed to be nested.
  80
  81 Compressed attributes
  82 =====================
  83
  84 The attribute value of each $DATA attribute can be compressed to save space.
  85 If this is the case, the ATTR_IS_COMPRESSED flag is set.
  86
  87 See the discussion on compression in include/attrib.h for more details.
  88 FIXME: The discussion belongs here! (AIA)
  89
  90 Sparse attributes (NTFS 3.0+)
  91 =============================
  92
  93 The attribute value of each $DATA attribute can be sparse to save space.
  94 If this is the case, the ATTR_IS_SPARSE flag is set. Note, that compressed
  95 attributes are by definition sparse, as well as compressed, without having the
  96 ATTR_IS_SPARSE flag set.
  97
  98 See the discussion on compression in include/attrib.h for more details.
  99 FIXME: The discussion belongs here! (AIA)
 100
 101 Encrypted attributes (NTFS 3.0+)
 102 ================================
 103
 104 Since NTFS 3.0, the attribute value of each $DATA attribute can be encrypted,
 105 to protect the contents from spying eyes. If this is the case, the
 106 ATTR_IS_ENCRYPTED flag is set.
 107
 108 FIXME: Write notes on attribute encryption. The descussions from the articles
 109 "Inside the Encrypting File System" in Windows NT magazine (?) are very good
 110 starting points. (AIA)
 111