[boburning]

Summary

Freshly formatting a previously used SD card can leave tens of GB marked occupied because the Windows FAT32 formatter initializes only the first 16 sectors of each FAT. On a 256 GB card, a fresh spruceOS installation showed about 33.7 GiB used for approximately 3.5 GiB of files; CHKDSK reclaimed 31,037,760 KiB of orphaned allocations.

- initialize only the first 16 sectors of each FAT
+ initialize every sector of both FATs in bounded, aligned 64 KiB writes

Preserve the media descriptor, reserved end-of-chain marker and root-directory allocation. Use the same writer in production and regression tests, and propagate failed or short writes. Add Linux/Windows CI that tests this writer without accessing a physical disk.

Evidence

• Before: the regression test against the previous initialization logic fails at a 17-sector FAT with stale allocation entries.
  After: both regression tests pass, including large prefilled tables, the old cutoff, chunk/tail boundaries, reserved entries, surrounding-data preservation, alignment, and write failures in either FAT.
• All 18 application tests passed with cargo +1.99.1 test --no-default-features. The existing manifest requires regenerating the upstream lockfile locally; that dependency-only change is excluded.
• The production formatter and Win32 adapter pass a focused Windows GNU cross-compilation against windows = 0.58. A full Windows application cross-check was blocked by the unavailable MinGW C compiler.
• Two independent source reviews found no actionable issues. Physical-device formatting with this patch has not been performed.

Merge Danger

Door: two-way for the code change. Formatting remains an inherently destructive operation; this patch does not repair already-formatted cards.

Blast Radius: Windows custom FAT32 formatting. Both FATs are fully initialized before the root directory is written; writes stop on the first error.

[Sundownersport]

Oooooo this might be the solution to a long standing bug! I’ll take a look thank you!