mirror of
https://github.com/reactos/reactos.git
synced 2024-07-04 03:34:16 +00:00
6ff94017e4
(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 |
||
|---|---|---|
| .. | ||
| btrfslib | ||
| cdfslib | ||
| ext2lib | ||
| ffslib | ||
| ntfslib | ||
| reiserfslib | ||
| vfatlib | ||
| vfatxlib | ||
| CMakeLists.txt | ||