Disk research

This is a Rust-based tool that brute-forces old DOS disk utlity behavior due to a lack of formal documentation. The process:

1. Create hard disk images of every conceivable geometry.
2. Boot Qemu i386 into DOS from a boot floppy.
3. Run FDISK through a Qemu i386 emulation and choose the default to use the whole disk.
4. FDISK requests a reboot. Just stop the process here.
5. Spawn a new Qemu process that picks up the freshly partitioned disk image.
6. Run FORMAT on the new partition.
7. Shut down Qemu.
8. Pull as much relevant metadata as possible from the BPB and partition table and put that in a database along with the 512-byte raw boot sector and some information on this specific run-attempt itself: did we succeed? Where did things break (if appropriate)? What parameters were used for the disk image creation, particularly geometry? Which OS and boot floppy were used?

This should run in parallel on as many cores as the host machine has, because it'll take thousands upon thousands of disk images. To not destroy the host SSD, we should also put the hard disk images in a tmpfs storage area.

The result is a SQLite3 database with a whole slew of disk metadata for how FDISK and FORMAT behave on every conceivable disk geometry. This gives an authoritative answer to the question how these tools behave on different disks and for different operating systems without reverse-engineering the tools themselves.

Current managed boundary

For the immutable PC DOS 3.00 fixture, the implemented managed path closes FDISK as inconclusive, starts a distinct second QEMU process, and proves readiness only by the reviewed A> prompt. It can then atomically begin the FORMAT stage, send FORMAT C: exactly once, and retain a live one-way typestate only after matching the exact reviewed confirmation screen. It sends no confirmation response and does not claim FORMAT, partitioning, shutdown, or metadata extraction succeeded.