ntfs-update-sequence-array · shipping · also NTFS fixup array, NTFS multisector transfer protection

NTFS update sequence array

An NTFS update sequence array stores a cyclic marker and displaced trailer words used to check protected multisector records before restoring those words.

Related Observatory article: NTFS update sequence array on hesela.com

The NTFS v3 contract compares the final two bytes of each 512-byte stride with the array marker before restoration. This is a record-transfer check, not a checksum over every byte. [1]

In Hesela's bounded native-library fixtures, altered interior bytes and saved trailer words were accepted, as were mixed records with equal markers; unequal markers were rejected. These results test one packaged NTFS-3G routine, not Windows or a mounted filesystem. [3]

For a 1024-byte fixture the tested count field is three 16-bit elements, occupying six bytes. The MULTI_SECTOR_HEADER documentation labels UpdateSequenceArraySize as bytes, while the pinned implementation treats usa_count as an element count; use the explicit layout and tested version when writing a parser. Its pre-write counter wraps from 65534 to 1. Neither a matching nor a newer-looking marker proves record identity or freshness. [1] [2]

Do not confuse this record marker with the NTFS USN change journal, which tracks file and directory changes. [4]

Fixup routines also depend on buffer state. In 24 additional NTFS-3G lifecycle controls, repeated read fixup rejected already-restored bytes; double pre-write protection followed by a successful checked read lost the original trailer payload. Properly paired writer calls preserved it. The post-write restoration helper returns no status and performs no marker validation, so it is not a substitute for checking input. These are deliberate caller-misuse controls, not observed production defects. [5] [2]

Relations

related

NTFS, Torn write, Checksum, Lost write

Limitations

• A successful fixup check is not evidence that file contents match a trusted original.
• The experiment uses synthetic record headers, not full MFT parsing or a drive-fault workload.

Citations

1. Microsoft: MULTI_SECTOR_HEADER, NTFS 3.0/3.1, 512-byte sequence stride (accessed 2026-10-23)
2. NTFS-3G mst.c, commit 78414d93613532fd82f3a82aba5d4a1c32898781: validation, restoration and counter wrap (accessed 2026-10-23)
3. Hesela: native NTFS-3G update-sequence fixtures, 36 read cases and five write transitions (2026-10-23) (accessed 2026-10-23)
4. Microsoft: Change Journals, a separate NTFS change-tracking facility (accessed 2026-10-23)
5. Hesela: native NTFS-3G lifecycle controls, 24 sequences and 48 calls per capture (2026-10-23) (accessed 2026-10-23)

JSON: /data/terms/ntfs-update-sequence-array.json