[VFATLIB] Fix FAT partitions formatting in a non clean fashion.
authorPierre Schweitzer <pierre@reactos.org>
Tue, 20 Feb 2018 23:16:36 +0000 (00:16 +0100)
committerPierre Schweitzer <pierre@reactos.org>
Tue, 20 Feb 2018 23:26:13 +0000 (00:26 +0100)
commit6ff94017e45a810acf73e0b5e4f39b3c8f822c83
tree1735c55351dc9aa04d5b0aff043eb8e32bdcbb61
parente1bd79e3df9a8a31652fda867a3a80b775e2a488
[VFATLIB] Fix FAT partitions formatting in a non clean fashion.

(So the fun begins)
In spite of what VFATLIB headers pretend, there's not magic in FAT boot sector.
The 3 first bytes are just the jump instruction (to the boot code). No jump, no boot.
Also, some (many?) FAT implementations rely on the jump code to help detecting that
a FAT volume is really a FAT volume. Like MS FastFAT. Or our own FAT recognizer in FS_REC.
The story is that, up to that commit, we zeroed the 3 first bytes; leading to broken
FAT volumes.
This got hidden in most cases by the fact that during setup, when we install boot
loader, we erase parts of the boot sector, including the jump instruction, making the
volume valid again. But that wouldn't fix secondary volumes where the boot loader isn't
installed.
And, also, imagine a scenario where you want to install ReactOS on a newly formatted volume
with MS FastFAT instead of our own implementation... That would simply not work to
the fact that the driver wouldn't recognize the fresh formatted volume!

(So the non fashion begins)
Fix this by putting a not that valid jump into the boot sector when formatting our
partitions. That way, our volume is always regarding a FAT view point. But, instead of
putting values that mean (nearly) nothing. We should also put a dummy bootloader
displaying the user and error message, as done by dosfstools.

(So the hope begins)
This opens the way for trying to install ReactOS with MS FastFAT (doesn't work yet).

CORE-11819
CORE-14362
sdk/lib/fslib/vfatlib/fat12.c
sdk/lib/fslib/vfatlib/fat16.c
sdk/lib/fslib/vfatlib/fat32.c
sdk/lib/fslib/vfatlib/vfatlib.h