Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

FAT32 drive on GPT (Miscellaneous)

posted by boeckmann, Aachen, Germany, 02.09.2023, 12:54

> In my USB program, by default it only assigns drive letters to compatible
> (FAT-formatted) partitions. To identify what's in the partition, though,
> it can't use the GPT entry. It must look at the data in the first sector
> (volume boot record) of the partition to see what's actually there (if
> anything).
>
> This is different than MBR, where you can (at least theoretically) tell how
> a partition/volume is _supposed_ to be formatted (even if it hasn't yet
> been formatted) by the partition type value in the MBR.
Exactly, the supposed file system type is encoded by the type number of the partition table entry. For NTFS partitions, it is a different number than for the FAT types (there are several). But even here, Microsoft started assigning several file system types to one type number, namely HPFS / NTFS / ExFAT, which all have partition type 7. Luckily, that is not of interest to DOS, as long as no one comes along and wants to implement ExFAT :-)

The actual FAT type "is determined solely by the count of clusters on the volume", and not by the partition type id, according to the Microsoft FAT specification [1], page 14.


> It seems like it might also be possible to create a FORMAT program that
> doesn't require a drive letter as input.
Yes, this proof has been provided several times :-)

For example, RANISH partition manager [2] is capable of it, but it is MBR only. I do not know any partition manager that a) supports GPT, b) runs under DOS and c) can format partitions.

> Maybe that's the better approach, but it seems like it would also
> be possible to create a "smarter" FORMAT program that could make up for
> some of the shortcomings in FDISK?
I think a "better" approach would be to store some FreeDOS specific hidden flag for the partitions the user does not want to see. Then everything else could stay as it is.

But it will be difficult, if not impossible, to store this information in the GPT itself without breaking compatibility. So some other location has to be found that a) does not break things and b) is accessible early in the boot phase while the Kernel enumerates the drives.

Bernd

[1] https://academy.cba.mit.edu/classes/networking_communications/SD/FAT.pdf
[2] https://codeberg.org/boeckmann/ranish/releases

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 89 users online (0 registered, 89 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum