[NTOSKRNL]
authorPierre Schweitzer <pierre@reactos.org>
Thu, 31 Oct 2013 18:03:48 +0000 (18:03 +0000)
committerPierre Schweitzer <pierre@reactos.org>
Thu, 31 Oct 2013 18:03:48 +0000 (18:03 +0000)
commit15743f252121d6370163ff46b735d5e8d90785b4
tree728638a05251f9aeba6c1e94a995cdcc14a12883
parentadf03f838aaa2ccfbbe890bacb142835cce6d3a2
[NTOSKRNL]
- Finally fully implement FstubVerifyPartitionTableEFI(). It is capable of fixing a GPT disk.
- Fix implementation of FstubReadHeaderEFI() (which returns a pointer to the header). Fixed all the other functions accordingly. Note that you have to be careful when using Disk->Buffer. You can easily read a buffer that doesn't contain your data anylonger.
- Fix implementation of FstubReadPartitionTableEFI(). It was improperly dealing with the backup table. Now, it will look for it and replace/recreate it if not found where expected.
- Fix implementation of FstubWriteEntryEFI(). The computation of memory placement was wrong, and thus it was missing partitions and causing corruption. Thank you checksums!

In case you format a disk with GPT using Linux (with GParted, for instance), don't be surprised if once started with ReactOS your GPT is modified, and especially its backup table moved. They don't have the same sector counts.
It was a nice way to tests whether ReactOS properly write GPT. Which it does now :-).

svn path=/trunk/; revision=60811
reactos/ntoskrnl/fstub/fstubex.c