Hello Joey,
"Joey Oravec" joravec@drewtech.com wrote:
- This code assumes that sector 0 contains a VBR. Instead I think it
should decide if 0 is an MBR or VBR, or even better utilize the dev:part command line. Can I make this determination that from the first three bytes, or is there a better way?
We have a patch in the queue to fix this, but it did not pass our internal review and unfortunately the engineer is on vacation right now so he cannot clean it up. Please be patiend for a week or two.
I wanted to share that with the list in case anybody else gets stuck.
Since my original email, I noticed code in fat_register_device() which determines a part_offset for 1.1.5 and 1.1.6. For now I've hacked this code to check the first three bytes EB:xx:90 or E9:xx:xx to make the mbr/pbr decision instead of the ascii string. Also I have it reading the valid partition offset instead of assuming 32. And finally I added a packed attribute to all structs.
I am not sure if we can use EB:xx:90 or E9:xx:xx (Am I right, this is the "Jump instruction to boot code" on a PBR?) for deciding between a MBR and a VBR, because the First 446 Bytes from a MBR are only "Bootcode", whatever this means, and maybe there is a MBR with EB:xx:90 or E9:xx:xx in the First 3 Bytes ...
- The decision of fat12, fat16, and fat32 is made upon fat_length and an
ascii field. The Microsoft document claims that the determination shall be made only by the count of clusters. Any disputes on that fix?
I have no idea...
I was reading a document "FAT: General Overfiew of On-Disk Format" v1.02 May 5, 1999 by Microsoft Corporation. The correct way is to calculate CountofClusters. Less than 4085 is FAT12, less than 65525 is FAT16, anything else is FAT32. I'll watch, and after he gets back from vacation we can do something about it.
This sounds good to me.
Do you have a patch for me, so I can test it?
thanks Heiko