Obtain a list of partitions on Windows

Question

Goal

I'm porting a filesystem to Windows, and am writing a more Windows-like interface for the mounter executable. Part of this process is letting the user locate a partition and pick a drive letter. Ultimately the choice of partition has to result in something I can open using CreateFile(), open(), fopen() or similar.

Leads

Windows seems to revolve around the concept of volumes, which don't seem quite analogous to disks, and only occur for already mounted filesystems.

Promising leads I've had include:

• IOCTL_DISK_GET_DRIVE_LAYOUT_EX
• Physical Disks and Volumes
• Displaying Volume Paths

However these all end in volumes or offsets thereof, not the /dev/sda1 partition-specific-style handle I'm after.

This question is after a very similar thing, I considered a bounty until I observed the OP is after physical disk names, not partitions. This answer contains a method to brute force partition names, I'd like to avoid that (or see documentation containing bounds for the possible paths).

Question

I'd like:

• Correct terminology and documentation for unmounted partitions in Windows.
• An effective and documented method to reliably retrieve all available partitions.
• The closest fit to the partition file abstraction as available in Linux, wherein all IO is bound to the appropriate area of the disk for the partition opened.

Update0

While the main goal is still opening raw partitions, it appears the solution may involve first acquiring a handle to each disk drive, and then using that in turn to acquire each partition. How to enumerate all the disk drives (even those without mounted volumes on them already) is required.

Longfellow

See https://mcmap.net/q/223994/-how-to-list-physical-disks/… – Inflict

@Amigable Clark Kant: You mean the question I linked to already? – Longfellow

hmm, yes, but specifically that answer. – Inflict

Answer 1

As you noted, you can use IOCTL_DISK_GET_DRIVE_LAYOUT_EX to get a list of partitions.

There's a good overview of the related concepts here. I wonder if the missing link for you is

Detecting the Type of Disk

There is no specific function to programmatically detect the type of disk a particular file or directory is located on. There is an indirect method.

First, call GetVolumePathName. Then, call CreateFile to open the volume using the path. Next, use IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS with the volume handle to obtain the disk number and use the disk number to construct the disk path, such as "\?\PhysicalDriveX". Finally, use IOCTL_DISK_GET_DRIVE_LAYOUT_EX to obtain the partition list, and check the PartitionType for each entry in the partition list.

The full list of disk management control codes may have more that would be useful. To be honest I'm not sure how the Unix partition name maps onto Windows, maybe it just doesn't directly.

Shopkeeper

Looks decent at least to me. +1. – Inflict

How do you map the partitions to paths? – Longfellow

@Matt Joiner - this info is available via GetVolumePathName, based on filename input. Still looking for a way to enumerate the drives. – Shopkeeper

@Matt Joiner - you can enumerate the volumes using FindFirstVolume/FindNextVolume. Given that, you can enumerate the partitions as above, and implicitly this gives you all the disks. See example here - msdn.microsoft.com/en-us/library/cc542456(v=VS.85).aspx – Shopkeeper

@Steve: I think you might still miss out on a PhysicalDisk object that has no associated volumes (because the partition table is either non-existent, empty, or contains only partitions with unsupported types) – Interphone

Based on Steve Townsend suggestion I have developed a small library called libwindevblk (github.com/vrichomme/libwindevblk) that allows to get a list of drives/partitions and their corresponding volumes/drive letters. It allows also to read/write with a simple API. The library uses setupapi to retrieve the drives and IOCTL_DISK_GET_DRIVE_LAYOUT_EX to get the partition. You just need to be careful if you want to get the partition number from a removable media because in my tests this number was sometimes irrelevant and I had to ignore the PartitionNumber from PARTITION_INFORMATION_EX – Remise

Answer 2

If you can imagine moving from safe haven of userspace and the Windows API (win32) to coding a device driver with NTTDK, you could try IoReadPartitionTableEx or some other low level disk function.

Inflict

Seems very similar to what win32 provides, but it lacks the ability to lookup the available disks in the first place. There's also a note: IoReadPartitionTableEx must only be used by disk drivers. – Longfellow

I am upvoting this because it's useful info in the (obscure) area of the question, even if not a full answer for @Matt. – Shopkeeper

Answer 3

To be blunt, the best way to reliably get all mounted/unmounted disk partitions is to parse the mbr/gpt yourself.

First to clear a few things up: Disks contain partitions and partitions combine to create volumes. Therefore, you can have one volume which consists of two partitions from two different disks.

IOCTL_DISK_GET_DRIVE_LAYOUT_EX is the closest solution you're going to get without doing it manually. The problem with this is that it relies on windows which can incorrectly parse the MBR for god knows what reason. My current working theory is that if Windows was installed via EFI but is being booted via MBR, youll see this sort of issue. Windows manages to get away with this because most partition managers copy the important partition information to the MBR alongside the GPT. But this means that you wont get important information like the partition UUID (which is only stored in the GPT).

All of the other solutions involve getting the Volume information which is completely different from the partition information.

Side Note: a Volume id will usually be of the form \\.\Volume{PARTITION_UUID}. Cases where this would not hold: if the drive is partitioned with MBR and not GPT (MBR does not have a partition UUID, therefore windows makes one up), if you have a raid drive, or if you have a volume consisting of partitions from multiple disks (kinda the same thing as raid). Those are just the cases that come to my mind, dont hold me to them.

Doody

Answer 4

I think you're slightly mistaken in an earlier phase. For instance, you seem to assume that "mounting" works in Windows like it works in Unix. It's a bit different.

Let's start at the most familiar end. Paths like C:\ use drive letters. Those are essentially just a set of symbolic links nowadays (On Windows, they're more formally known as "junctions"). There's a base set for all users, and each user can add their own. Even if there is no drive letter for a volume, there will still be a volume name like \\?\Volume{4c1b02c1-d990-11dc-99ae-806e6f6e6963}\. You can use this volume name in calls to CreateFile() etc. I'm not sure if fopen() likes them, though.

The function QueryDosDevice will get you the Windows device name for a drive letter or a volume name. A device name looks like "\Device\HarddiskVolume1", but you can't pass it to CreateFile

Microsoft has example code to enumerate all partitions.

On Windows, like on Linux, you can open the partition itself as if it were a file. This is quite well documented under CreateFile.

Sporadic

The example code you've linked to is already in my list of leads, and only appears to work for mounted volumes. Furthermore it isn't specific to partitions. I need to access unmounted stuff. – Longfellow

Well, the concepts don't really translate. Windows doesn't have a "mount" concept, so the concept of an unmounted partition doesn't make sense either. Are you talking about the collection of sectors on a disk which are part of a filesystem for which Windows doesn't have a driver? There's no object in Windows that represents those sectors, AFAIK. – Sporadic

Note: a volume and a partition (in windows) is NOT the same thing. Disks have partitions and partitions compose volumes. You can have 2 partitions from different disks composing the same volume. – Doody

@chacham15: While it is true that there are exceptions to "volume == partition", such as RAID stripe sets, I don't think those exceptions apply here. – Interphone

@BenVoigt: Correct. Since we're talking about bits of disk not yet recognized, it would not make sense to talk about volumes spanning multiple disks. That would require that Windows understands the partitions making up that volume. – Sporadic

@BenVoigt The OP asked about correct terminology and I provided some. MSalters incorrectly used the terminiology as well when he said that MSFT provided a way to enumerate the partitions. The sample code does not enumerate partitions but rather volumes. While, it may not be directly relevant to OP, the misuse of terminology is only going to confuse him and others. To that end, the link provided is also not useful exactly because it returns Volumes and not Partitions (which isnt useful because MSFT needs to understand the partitions to create the volumes). – Doody

@chacham15: The Volume enumeration code linked does fall short, I agree. The data it returns do correspond to partitions, but not all partitions, only the ones with a type Windows recognized and created a volume object for. – Interphone

@BenVoigt right, thats the problem, if you want to see unrecognized partitions it wont show up in the volume list. – Doody

@chacham15: I also think this answer missed the salient point about the difference between Windows and Unix mounting -- on Windows, the volume path (and drive letter, if enabled) is assigned to every recognized partition upon detection, and not as part of the mounting process (and is completely independent of the filesystem). – Interphone