You've come to this page because you've asked a question similar to
I have a disc volume. How do I determine the type of the filesystem that with which it was formatted?
This is the Frequently Given Answer to that question. (Please note that it is not the answer to the different question of how to determine the FAT width of a volume that you already know to be formatted with the FAT filesystem.)
If the volume is the whole of a non-partitionable physical disc (i.e. a "floppy" or a "superfloppy" disc), you read block 0 of the volume and look for various kinds of filesystem type signatures.
If the volume is a partition on a partitionable physical disc, then you use the partition type first of all to determine the primary detection method to employ to discover the filesystem type. For some partition types, you read (volume-relative) block 0 of the volume (the Volume Boot Record or "boot block") and look for various kinds of filesystem type signatures (such as BPBs). For other partition types, you read (volume-relative) block 1 of the volume and look for various kinds of filesystem signatures. For yet other partition types, you read yet other blocks, and look for various kinds of filesystem signatures.
Traditionally on PC operating systems, the partition type has been associated with one, and only one, filesystem type. However, this was never the intention, and in practice is true only for a limited number of partition types.
The intention of the partition type was to prevent operating systems from attempting to access, mount, write, or otherwise deal with partitions that they wouldn't know how to deal with (because they would exceed their preconceived notions of how large a disc volume could ever be, for example), or that would extend into areas of the disc that they wouldn't be able to access, or that simply weren't volumes containing files and directories at all.
The idea that the partition type implies the filesystem type is flawed in any
case, for one very simple reason: Once a partition has been created with a
disc partitioning utility, users can (and do) reformat it with any
filesystem type that they like. Most volume formatting tools (i.e.
"high-level formatting" tools — mkfs and pals in Unix
parlance) operate solely upon the contents of the disc slice
concerned. They don't look for, and modify, the disc partition table
to ensure that the partition type matches the new filesystem type.
What a partition type does is define which operating systems will attempt to access, mount, write or otherwise deal with the partition, and define the particular detection method that is to be used to determine what filesystem type the volume is actually formatted with.
| GUIDs and descriptions | Implied filesystem type detection method | Details | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
None |
This is an internal GUID partition table type, used to signify partition table entries that are available for use, that never applies to actual disc slices. |
|||||||||
|
Probe the volume's boot block (block 0) for a BPB. |
These are the various EFI partition table types where the filesystem type is determined by probing the volume's boot block for a BPB. Note that whilst the EFI System partition is defined as only ever being formatted with the FAT filesystem type, that is not an implication of the partition type. It is an additional constraint imposed by EFI so that there is only the one filesystem type that system firmware must always be capable of handling. The purpose of the partition types is to control which operating systems will attempt to mount, access, and write to the partitions, to control to whom they will be visible, and to allow partitions of specific types to be automatically located and used. It is not to define the filesystem type. For examples: Machine firmware on EFI machines will automatically look for partitions with the EFI System partition type, and operating systems will generally make partitions of this type invisible to users in the normal course of operation. Microsoft Windows will attempt to automatically mount all partitions with the Microsoft Data partition type.
Linux mis-uses the Microsoft Data partition, by creating volumes in it
that do not have valid BPBs. This is a fault in Linux. (EXT2/EXT3/EXT4
partitions could easily be given BPBs. In actual fact, the
|
|||||||||
|
None |
These EFI partition table types are used to protect physical discs partitioned with other partitioning schemes from softwares that do not understand those schemes and that only understand the EFI GUID partitioning scheme. They encompass the entire slice of the disc that is partitioned using the other partitioning scheme, including its partition tables. EFI specifically precludes partitioning schemes from being mutually recursive. An EFI GUID partition table may not be contained as a secondary partitioning scheme within another primary partition scheme. It may only contain other schemes. |
|||||||||
|
None |
These are the partition types used by various disc partitioning utilities when creating partitions to hold swap space. They are used to hide such partitions from operating systems that would otherwise attempt to probe the blocks of the volume for filesystem signatures and mount a volume on the partition.
They are different from one another because different operating systems
require their swap partitions to be pre-initialized (with
|
|||||||||
|
None |
These are the partition types used by OEMs to hold OEM-specific maintenance and diagnostic tools. |
| Byte values | Implied filesystem type detection method | Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x00 | None |
This is an internal MBR partition table type, used to signify partition table entries that are available for use, that never applies to actual disc slices. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 0x05 0x0F 0x42 0x85 0xA5 0xA6 0xA9 0xEE | None |
These MBR partition table types are used to protect physical discs partitioned with extended partitioning schemes from softwares that do not understand those schemes and that only understand the primary MBR partitioning scheme. They encompass the entire slice of the disc that is partitioned using the other partitioning scheme, including its partition tables. For the EFI partitioning scheme, the disc slice encompassed is required to be the entire disc. The other partitioning schemes have no such requirement. This is a fundamental difference between EFI and the other partitioning schemes. With EFI, the EFI partitioning scheme is the primary partitioning scheme of the disc. The "protective MBR" is just a compatibility feature, not a definitive means for determining where the EFI partition table is and what parts of the disc are allocated to EFI partitioning. With the other partitioning schemes, the MBR partitioning scheme is the primary partitioning scheme of the disc, and the other schemes are secondary schemes that are effectively nested within it, using the MBR partitioning to determine where their own partition tables are and what parts of the disc they may lay claim to. With EFI, MBR partitioning only nests within an EFI partition, not the other way around. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Probe the volume's boot block (block 0) for a BPB. |
In theory, according to much prevalent MBR partition documentation that has been cobbled together by third parties over the years, the partition type indicates the filesystem type in bits 0–3, with bit 5 always being zero, and bits 7, 6, and 4 of the type being various flags used to "hide" partitions (from operating systems) and to signify fault-tolerance attributes of partitions.
In practice, tools such as Partition Magic, the Graham Utilities, and
even the humble In fact, Microsoft operating systems have never used the partition type to determine the FAT width of a volume formatted with the FAT filesystem, despite what most MBR partition table documentation states. The association between the partition types and FAT widths given in most MBR partition table documentation is in fact an historical accident. The partition types had nothing to do with indicating the FAT widths. The actual purposes of the new partition types were to hide FAT partitions from older versions of MS/PC-DOS and DOS-Windows that wouldn't be capable of handling them properly (because they would be larger than they knew how to handle, or would extend into or be located in portions of the disc that they couldn't reach). Operating systems use the type to determine whether they should attempt to mount the partition as a disc volume. Older versions of MS/PC-DOS and DOS-Windows wouldn't attempt to mount partitions with the new types, making it safe for such partitions to exceed partition size and location constraints hardwired into those older operating systems. The false association with the FAT widths resulted from the fact that the introduction of the larger FAT widths accompanied the introduction of the new partition types. However, they are not associated. Type 0x0B wasn't introduced to indicate FAT32. It was introduced because FAT32 partitions might be larger than 2GiB, and MS/PC-DOS versions 6.22 and earlier simply couldn't cope with partitions that were that large, because they assumed all partitions to be smaller than 2GiB. Similarly, type 0x04 doesn't imply FAT16. It could easily be a FAT12 partition. (With a 32KiB cluster size, FAT12 supports volumes up to 128MiB.) What it implies is that the partition might be larger than 16Mib, and MS/PC-DOS versions 2.x and earlier simply couldn't cope with partitions that were that large, because they assumed all partitions to be smaller than 16MiB. Type 0x07 doesn't imply non-FAT. It is simply that MS/PC-DOS and DOS-Windows assume that every partition is some flavour of FAT, and don't properly check the BPB to determine the filesystem type. See Microsoft's KnowledgeBase article #69912 for all of the preconceived size limits in the various versions of MS-DOS and DOS-Windows that have required new partition types to be invented whenever they have been exceeded. If Microsoft operating systems hadn't been hardwired to only expect partitions to be no larger than certain specific sizes, if the PC firmware had provided logical block access to disc units right from the start, and if Microsoft operating systems had been written to fail gracefully when they encountered partitions that were unexpectedly larger than the FAT widths that they knew about could cope with, there would have been no need for all of these extra partition types, and all partitions that Microsoft and Microsoft-compatible operating systems were expected to understand would have the same single type: type 0x01. Just as is the case with the Microsoft Data partition in the EFI partitioning scheme. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 0x0A | None |
This is the partition type used by IBM's Boot Manager. It is used to hide such partitions from operating systems that would otherwise attempt to probe the blocks of the volume for filesystem signatures and mount a volume on the partition.
Some operating systems do probe the blocks of the volume anyway,
because they think that type 0x0A is in the "probe block 0 for a BPB"
group of partition types. And, indeed, IBM Boot Manager partitions
do in fact contain a BPB in their boot blocks that specifies
"
Most notoriously, Windows NT 2000 does this. It probes the boot blocks of
type 0x0A partitions, sees the BPB, thinks that the volume is formatted as
a FAT filesystem, runs Both parties are at fault here: IBM Boot Manager for having a BPB that says that the filesystem format is FAT when it actually isn't, and Windows NT 2000 for thinking that type 0x0A partitions are in the "probe the volume boot block for a BPB" group when they aren't.
The solution to this is simple: Increase the |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 0x82 | Probe the ext2/ext3 superblock for a signature. |
This is the partition type used by most Linux disc partitioning utilities when creating partitions to hold ext2 and ext3 volumes. It is used to hide such partitions from operating systems that don't know how to probe ext2/ext3 superblocks. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 0x83 | None |
This is the partition type used by most Linux disc partitioning utilities when creating partitions to hold swap space. It is used to hide such partitions from operating systems that would otherwise attempt to probe the blocks of the volume for filesystem signatures and mount a volume on the partition. |
Unfortunately, due to a very poor piece of design on Microsoft's and IBM's parts, the signature fields of the various types of BPB are not in the same place. So the signature byte in one kind of BPB is an entirely different field in another kind of BPB. Furthermore, there is no magic number to indicate that a boot block even has a BPB at all. (No, the 0xAA55 signature at offset 0x1FE does not perform this function, because (a) it also occurs in MBRs, and (b) too many filesystem creation utilities omit it when creating volume boot records. The "OEM name" field, whose handling by Linux and by various Microsoft operating systems is a design disaster in its own right1, does not perform this function, either.)
These have the unfortunate consequences that it is harder than it need have been to determine whether a BPB exists in a boot block and what type of BPB it is.
(Design tips that can be learned from this mess: For variant records, always locate your signature fields at the same byte offset into the record. Where a variant record can also be absent entirely, include some kind of additional signature, such as magic number that is at least 32 bits wide or a pair of record length and record checksum fields, to indicate the mere presence of the record.)
The algorithm for probing for BPBs is as follows:
Read the volume's boot block, (volume-relative) block number 0.
Inspect the version 7.0 BPB's signature byte at offset 0x42. If the signature is not the value 0x28 or the value 0x29, then this is not a version 7.0 BPB. Go to step #5.
This is (probably) a version 7.0 BPB. But it also might be another sort of BPB that just happened to have the right value in the signature byte. Inspect its filesystem type field at offsets 0x52–0x592. Filesystem type fields that contain anything other than alphanumeric ASCII characters and spaces strongly indicate that this is not a version 7.0 BPB, and that the signature byte matched by accident. If this is the case, go to step #5.
The filesystem type is what is in the filesystem type field of the version 7.0 BPB3. You're done.
Yes, it's reasonable to accept types such as
"HPFS ",
"EXT2 ",
"FAT16 ", and
"FAT12 ",
with a version 7.0 BPB. These may be unusual in a version 7.0 BPB, but
are perfectly valid. Despite the fact that it is often erroneously
referred to as a "FAT32 BPB", there's nothing inherent in a version 7.0
BPB that precludes it from being used with any of these filesystem types.
(Indeed, a FAT12 or FAT16 volume with a version 7.0 BPB will gain a backup
boot block and a superblock. An HPFS or EXT2 volume with a version 7.0
BPB will gain the ability to relocate the superblock away from the fixed
location that is otherwise the case for those filesystem types.)
Vanilla NTFS cannot employ a version 7.0 BPB. NTFS requires a BPB to
provide capabilities that simply aren't provided by version 7.0 BPBs. If a
version 7.0 BPB has "NTFS " in its
filesystem type field, then it is a version 7.0 BPB, and you
shouldn't proceed to check for other types of BPBs. But the filesystem
type is unlikely to be vanilla NTFS. (It's possible to define an
extension to vanilla NTFS where when a version 7.0 BPB is used the BPB's
root directory pointer is used to locate the MFT.)
Inspect the version 4.0 BPB's signature byte at offset 0x26. If the signature is not the value 0x28 or the value 0x29, then this is not a version 4.0 BPB. Go to step #8.
This is (probably) a version 4.0 BPB. But it also might be another sort of BPB that just happened to have the right value in the signature byte. Inspect its filesystem type field at offsets 0x36–0x3D2. Filesystem type fields that contain anything other than alphanumeric ASCII characters and spaces strongly indicate that this is not an version 4.0 BPB, and that the signature byte matched by accident. If this is the case, go to step #8.
The filesystem type is what is in the filesystem type field of the version 4.0 BPB3. You're done.
Neither vanilla NTFS nor vanilla FAT32 can employ a version 4.0 BPB. They
both require a BPB to provide capabilities that simply aren't provided by
version 4.0 BPBs. If a version 4.0 BPB has
"NTFS " or
"FAT32 " in its filesystem type field, then
it is a version 4.0 BPB, and you shouldn't proceed to check for
other types of BPBs. But the filesystem type is unlikely to be
vanilla NTFS or FAT32.
(It is possible to define an extension to vanilla FAT32 where when a
version 4.0 BPB is used the root directory pointer is placed in entry #1
in the FAT, and there is no superblock. And it's possible to define an
extension to vanilla NTFS where when a version 4.0 BPB is used the first
MFT entry is located in a well-known fixed position relative to the end of
the reserved sectors, just as the superblocks of HPFS and EXT2 are located
in well-known fixed positions.)
Inspect the version 8.0 BPB's signature byte at offset 0x26. If the signature is not the value 0x80, then this is not a Windows NT BPB. Go to step #10.
This might not be an version 8.0 BPB. At 1 byte long the signature field is too short to be completely reliable. Unfortunately, it's all that one has in an version 8.0 BPB. Version 8.0 BPBs don't contain a filesystem type field that can be sanity checked. They do have a checksum field, and in theory that would allow version 8.0 BPBs to be recognized reliably. In practice, no Microsoft operating system sets the checksum field to any value other than zero, entirely undermining its purpose.
This unreliability of version 8.0 BPBs is why they must be checked for last, after first checking for all of the other types of BPBs where one gets to check both a signature field for a specific value and a filesystem type field to see whether it contains a sane value, thereby reducing the likelyhood of accidentally recognizing the wrong type of BPB.
The filesystem type is thus NTFS. You're done.
A recognizable version 7.0, version 7.0 BPB, or version 8.0 BPB has not been found in the boot block. If this is a partition on a partitionable disc and the partition type is that of a Microsoft Data partition (EFI partitioning) or is one of the IBM/Microsoft partition types where the implied filesystem type is FAT (MBR partitioning), then you might choose to employ a default assumption that the filesystem type is FAT.
However, this default assumption is invalid on non-partitionable discs and on partitions of other types (and is pretty shaky even on the aforementioned partition types). If a type 0x07 MBR partition has no recognizable BPB, it is downright wrong to assume that the filesystem type is FAT, for example. The same goes for "floppy" or "superfloppy" discs.
You might instead choose to try some of the other probes, of other blocks in the volume, looking for filesystem signatures, at your discretion. There is no requirement and no defined order for such alternative probes.
However, it is equally legitimate to simply assume that the volume has not been formatted.
IBM/Microsoft operating systems check the OEM Name field and use it to determine whether they believe the contents of the accompanying BPB. If they don't like the contents of the OEM Name field, they ignore the BPB that is on the disc, and make up one on the fly and use that, instead.
The fact that they still regard a BPB as being there, and merely replace its contents with contents of their own devising, is why the OEM name field does not perform the role of determining whether a BPB exists.
Naturally enough, Linux gets this wrong, and uses the OEM name field to determine whether a BPB exists at all, rather than to determine whether the BPB is (likely to be) sane and replace it with a sane one if not. This only compounds the problem.
It is important that you check the entire contents of the field, including the space padding. Checking just the first 3 characters is not enough.
Note that the filesystem type is not dependent from any other fields of the BPB. The filesystem type field is definitive.
Some people state that one checks other BPB fields, such as the count of root directory entries field, in order to determine the filesystem type of a volume. They are mistaken. They are conflating the two different operations of determining the filesystem type of a volume and determining the FAT width of a volume after one has determined that its filesystem type is FAT.
Unlike Microsoft's/IBM's design, the EXT2/EXT3/EXT4 filesystem format has a well-defined magic number field, at a well-defined single place that is always the same. The daft design choice in EXT2/EXT3/EXT4 comes in the definition of that place. It's not a specific numbered block. It's a specific number of bytes from the start of the volume. The (primary copy of the) superblock is defined to be located 1024 bytes from the start of the volume.
This may be all fine and dandy when one is reading a disc volume using a character device file in Unix or Linux, but it's non-trivial when one's I/O system works in terms of disc sectors, as it does for — well — operating systems, disc sector editors, filesystem diagnosis and repair utilities, PC firmwares, …
So one has to account for the bad design of EXT2/EXT3/EXT4 when finding and reading the superblock. If one's disc sector size is less than 1024, as it still is for most hard discs in PCs, then one divides 1024 by the disc sector size to find the disc sector number of the (first sector in) the superblock (which can also span several sectors). Otherwise the superblock is located at byte offset 1024 in sector zero of the volume.
The magic signature is a 2-byte word at byte offset 0x39 within the superblock itself. It contains the bytes 0x53 0xEF (i.e. it is the 16-bit value 0xEF53 in little-endian form). If the superblock contains this magic word then the filesystem type is EXT2/EXT3/EXT4.
So the algorithm for probing for EXT2/EXT3/EXT4 volumes is:
Work out what sector(s) byte offset 1024 corresponds to and read them.
Read the 16-bit signature word from the superblock and check that it is 0xEF53. If it is, this is an EXT2/EXT3/EXT4 formatted volume.1 You're done.
This isn't an EXT2/EXT3/EXT4 formatted volume. You might choose to assume that this is an EXT2/EXT3/EXT4 formatted volume anyway, but such an assumption is shaky, especially on non-partitioned discs, for much the same reasons that (say) assuming that a non-partitioned disc is "FAT" formatted when probing for a BPB has failed.
You might, similarly, instead choose to try some of the other probes, of other blocks in the volume, looking for filesystem signatures, at your discretion. There is no requirement and no defined order for such alternative probes.
However, it is equally legitimate to simply assume that the volume has not been formatted.
The magic number is definitive by itself. If it has the right value, then the filesystem type is EXT2/EXT3/EXT4. There are version number fields and flags words in an EXT2/EXT3/EXT4 superblock. But not only do they not define whether the filesystem type is EXT2/EXT3/EXT4, there are even forwards and backwards compatibility requirements that prohibit softwares from assuming that since they only know about EXT version 2, they cannot possibly handle EXT version 3 and EXT version 4.
The flags and version fields tell filesystem drivers and utility softwares what optional features it should expect or enable. The filesystem type is still EXT2/EXT3/EXT4.