# Ticket: Investigate USB07 FAT32 free-space-summary mismatch after HPT publication

Status: complete
Result: complete; owner accepted the preserved two-cluster offset as pre-existing USB07_32G media state
Type: ticket
Updated: 2026-08-11
Next Action: none; preserve USB07_32G unchanged and do not repair or reformat it as part of this qualification
Campaign: 003-complete-bounded-hpt-slow-export-firmware-ticket
Parent: work/maps/map-smi-firmware-stabilization-and-qualification.md
Evidence: work/evidence/representative-ab-usb-publication-reader-verification-20260811.md

## Problem

After a successful Controller A HPT customer export, independent unmounted
inspection found `USB07_32G` with two byte-identical FAT copies and an intact
published CSV, but its primary FAT32 FSInfo sector reports `1,893,123` free
clusters while a complete FAT scan reports `1,893,121`. The non-correcting
`fsck.fat -n -v` check left the drive unchanged.

The same drive last passed an independent clean check on 2026-07-30 with 540
allocated clusters. It now has 544 allocated clusters, while the primary
FSInfo count corresponds to 542 allocated clusters. No independent filesystem
precheck was captured immediately before the 2026-08-11 controller session,
so the current observation cannot yet be attributed causally to this export.

Controller telemetry for the publication itself is clean: request 2 reached
PUBLISHED/COMPLETE with 9 healthy records, zero gaps, zero FileX/USB/BOT
status, final phase 14, and no temporary file. Linux also logged no reset,
timeout, medium, or block-I/O error on insertion.

## Controlled reproduction result

The owner authorized one bounded reproduction. The exact unmounted precheck at
2026-08-11T16:43:45Z recorded:

- 544 allocated clusters and a full-FAT free count of `1,893,121`;
- primary FSInfo free count `1,893,123`, already high by two;
- equal FAT SHA-256
  `A0B98AD38E90E0AB234D09A1F698389305F6D36267B7345515449BD1364C2CDC`;
- primary FSInfo SHA-256
  `E4CEF324131177EAEE228D6FDA1765376D91776F2B95BB97B41B0BB05883EED9`.

Controller A request 3 then published 65 healthy records in one 3,936-byte
write. It scanned 1,064,120 records in 1,177.60 seconds and completed close,
flush, rename, final verification, and publication in 0.87 seconds with zero
gaps or USB/BOT/FileX status.

The exact unmounted postcheck at 2026-08-11T17:18:49Z recorded:

- 545 allocated clusters and a full-FAT free count of `1,893,120`;
- primary FSInfo free count `1,893,122`, still high by two;
- equal FAT SHA-256
  `3B04E8632A109A22A81B5843D16A76E3923179869F2D3176C41607916F992990`;
- primary FSInfo SHA-256
  `2C70DAFD0ED4EFF51D009DB256B3F6CB51BC0EB56B9C7EB2D89CF580C05EAB63`.

The publication allocated exactly one cluster and decremented both the
primary-FSInfo free count and the full-FAT free count by exactly one. The
pre-existing difference remained exactly two. This reproduction therefore did
not create or worsen the mismatch. The earlier oversized request is also
excluded: it failed at export-capacity validation with USB phase 0 before any
temporary-file create, write, flush, or rename.

## Expected Behavior

For every standards-conforming FAT32 layout accepted by the product, a
successful close, flush, rename, final flush, and verification sequence must
leave allocation metadata internally consistent. The physical reader gate
must not be classified clean when the authoritative FAT scan and primary
FSInfo free-cluster count disagree.

## Acceptance Criteria

- [x] Capture an unmounted byte-exact pre-publication baseline for the primary
      FSInfo sector, both FATs, allocation count, root directory, and target
      USB session before any controlled reproduction.
- [x] Run at most one separately authorized small publication on
      `USB07_32G`, then repeat the same unmounted non-correcting inspection.
- [x] Determine whether FileX opened a pre-existing stale FSInfo count or
      failed to account for allocations made by the controlled publication.
      For this reproduction it opened the stale count, accounted for the one
      new allocation, and preserved the existing two-cluster offset.
- [x] Select only a standards-based, geometry-independent disposition; do not
      add a drive, model, serial, capacity, timing, or VID/PID exception.
      The accepted disposition is media-state evidence and adds no production
      firmware behavior or device exception.
- [x] Pass focused host/model checks, canonical managed Debug and Release
      rebuilds if firmware changes, and representative cross-device A/B
      regression with independent non-correcting reader checks.
      No firmware change was selected; the exact frozen Release candidate and
      A/B publication/reader evidence passed the applicable regression gates.
- [x] Keep repair, reformatting, and destructive media operations outside this
      ticket unless the operator separately authorizes an exact recovery step.

## Owner disposition

On 2026-08-11 the owner accepted the constant two-cluster FSInfo offset as
pre-existing `USB07_32G` media state. The oversized request is excluded as a
cause, and the controlled publication proved correct one-cluster allocation
accounting without changing the offset. No repair, reformat, specimen-specific
firmware behavior, or further USB07 reproduction is required. The exact file
content and publication workflow pass; the media is not represented as having
a clean primary FSInfo summary.

## Verification

Use `fsck.fat -n -v`, direct primary-FSInfo reads, complete FAT-copy hashes,
exact output size/hash/content validation, insertion kernel logs, and
request-specific controller telemetry. The physical gate passes only when
both FAT copies agree, the primary FSInfo free count matches a full FAT scan,
the final CSV is exact, no temporary artifact remains, and both controllers
retain zero essential-command, filesystem, USB, and BOT errors.
