FATINFO.G4B: grub4dos script to get FAT-related information from devices or from image-files. Some basic tests and some silent operations too. More information: https://github.com/deomsh/FATINFO.G4B
Now and then I am working on a script to make FAT-images. To more quickly check the results I needed a grub4dos command-line tool and giving more information than grubutil fat with function info. Also fat info is only working with devices, not with image files (so endless mapping ...).
FATINFO.G4B can do both, only DEVICE or FILE are needed - one optional switch. In case of HDD-images offset is needed too.
There are some non-standard read-outs like Last allocated sector (NextFree) FSinfo in case of FAT32, and found last allocated cluster in case of FAT12/16.
With switch /T some basic tests are performed. Because of the nature of some boot sector values, not all tests have to be noted to be 'PASSED'. With a few other switches there is silent operation with export of a result variable or otherwise.
Some action print-screens, first three starting with read-out of fat info. Watch 'test' for FAT16 and FAT32 shutdown flag in the last two print-screens:
BTW in case of floppies the Media descriptor will be only reported as 'valid' if 'all' standard values are found.
BTW2 be aware fat info does not count the 'real' number of free clusters, but will report the FSinfo value (in case of FAT12/FAT16 counting is always needed). With switch /T FATINFO.G4B will do the count for FAT32, took about 3 seconds on my system in case of a 40GB partition.
BTW3 FSinfo values are ment as a 'hint' for the FAT-driver, according to Microsoft's specs.
Two print-screens of file-images. In second print-screen Jaclaz' tool MBRVIEW.G4B is used to find the offset to partition:
BTW MBRVIEW.G4B can be found on: http://reboot.pro/in...&hl=mbrview.g4b
FATINFO.G4B seems to be working on grub4efi too:
I did some experiments on 36.90 MB vhd's, all partitioned as FAT32 with MS-DOS 7.1 FDISK /fprmt. Then I checked formatting of MS-DOS 7.1 (hd1), Windows 10 (hd2), Paragon Partition Manager 17 (hd3), EaseUS Partition Manager 13.5 (hd4) and Active@Partition Manager (hd5) and again Windows 10 format from command-line (hd6).
FDISK used rather uncommon CHS-values, during formatting all, except MS-DOS 7.1 and Active@Partition Manager wrote other CHS-values. So balancing of the partition can not be judged anymore. Most changed the file system type too:
Only MS-DOS 7.1 wrote the original H/S -values to the boot sector, and got a positive result for ALL performed tests:
Windows 10 ignored the file system type and formatted to FAT16, further 'good':
Most interesting was Paragon Partition Manager 17, who changed type to FAT16, but still (forced!) created a fAT32 file system. Notable too: 7138 reserved sectors before start of FAT:
EaseUS Partition Manager 13.5 gave rather normal results, but according to my test the backup of the boot sectors was not valid. As can be seen on the print-screen the number of hidden sectors was missing in the backup of sector 0:
Only Active@Partition Manager did not change the MBR, but set Sectors per track and Number of heads to usual 'modern' values, if NOT balanced the test will report in this case 'Unknown ....':
Windows 10 again, formatted from command-line to force FAT32: only type changed to 0x0C and it seems Windows 10 wants temporary reserve one cluster, by setting FSinfo value one higher ???
BTW same high number of 7138 reserved sectors before start of FAT as Paragon ???