(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
It's critical not to perform any write on a volume without an exclusive lock on it.
That lock is only acquired if ChkDsk is started in RW mode.
Also added an assert in write routine, to make sure that when we're about to perform
a write operation, we're really allowed to do so.
This will avoid volume corruptions when a simple "chkdsk" is issued from cmd.
To put it simple: check will really check now, and won't attempt any repair.
CORE-14119
For instance, when repair is required, we can ask the caller whether we should
continue or not in case locking failed.
Also, introduced a hack for 1st stage where IopParseDevice() hack is in usage
so that broken NTSTATUS is diverted to appropriate status.
That way, usetup will properly continue even if locking failed (due to its
callback stub!)
CORE-14087
