The current 2.0 beta shows the drive's serial number in the disk open dialog.
Regarding the naming of drives, volumes, logical disks/physical disks etc. in Windows, I get where you are coming from, but I also think Windows' naming conventions are really messy.
Almost everything is a drive there, no matter what kind of hardware it really is, a thumb stick, a removeable disk (attachable over USB or one you can slide in an SATA dock), SD card, etc. Except for optical disks, such as CDs, which get their own separate numbers.
The numbering of the drives is really only based on the hardware abstraction, not the hardware's physical properties, so Windows just counts from 0 to n, even if the types of drives are pretty different. The numbers do not help to reliably identify what hardware device you are dealing with. Its use lies in correlating the device with the names it got in programs such as diskmgmt.msc (which unfortunately is also pretty terse in giving unique details about the device). In disk management you can only identify the hardware by size or serial number (if you go the additional step to check it's context menu and there select properties). It's internal Windows name is not displayed, just a human readable one that persumably correlates with \\.\PhysicalDrivex (Windows' internal names for disk like drives with or without inserted media). Regarding built-in tools, get-disk (powershell) seems to give the most informative disk list.
That's why I added this counting, divided by type of drive: to give more clues and not ignore drive type. Granted the counting is a little confusing in the situation with addon cards (as you described above). I started at 1 to make this distinction from Windows counting more obvious. There is definitely room for improvement. It's not trivial though, let me explain.
In the past (BIOS), the drive numbers Windows gave (took over) had a correlation with the physical port/place they were attached to, and drive type (floppy, IDE hard disk, SCSI, etc.). Now it's mostly arbitrary, since all kinds of attachments/ports are put in one big list, by whatever order Windows queries the various controllers/ports/etc. Well except for CDs/optical dics and tape drives, which are counted separately.
I.e., you could deduce the (cable) plug or docking port based on the device type and number, rather easily. This is not the case anymore, the Windows tools' disk number is now just an internal list index. Probably makes little sense, too, since for example USB ports have no numbers written on them, and couldn't have simple ones, since they can be chained into trees using hubs. So at most some sort of hierarchical, IP like numbering would work.
diskmgmt.msc also uses this uninformative counting, but it has a partition view which is quite useful. I plan to add something similar after 2.0.
In the following, all of this is discussed a little more structured, and a possible solution is given at the end.
Bad naming conventions in Windows
Disk and Drive is often confused in Windows, which doesn't make those terms that clear. To use disk alone for a physical disk is an unfortunate choice, since logical disk is a synonym for volume. Logical drive is also a synonym for volume, because a CD (or any other optical medium), is actually not a disk but a disc, and so it's not a logical disk, but a logical drive. Well, technically a logical disc, but nobody says that. Also, there are other types of storage, that are in their own category, like tape drives, network storage, etc.
Volume is also a bad choice for a name, it is void of any meaning, at least it hasn't multiple uses, yet. It really is a huge mess, and ideally, new terms should be used.
I would say storage reader/writer, and storage (medium) or just storage would be good choices. And then physical and logical storage. But again, it's not always clear what is physical or virtual. Some virtual devices show up as physical hardware.
Maybe I should rename this "Open storage" and not "Open disk", then again, many wouldn't find it at first.
Why it matters
To get more specific why this mess matters.
The number of DiskX is the number of PhysicalDriveX, which really designates the drive, not the medium. So for example it identifies the SD card reader, not the SD card, which can also be accessed when no SD card is in the reader (e.g., to query drive properties). What happens when there is no SD card inserted? Does it skip this drive when counting, and keep an internal count? So does it count disks or drives? All of this is really messy and can be tested/reversed engineered, but this is not reliable/may change (as many things in this domain have over time) and I haven't found a definite documentation of all of this.
So, I think that relying on the disk numbers is a bit risky in general
. Also, I noted various programs do differ in how they name drives/disks.
I haven't found any documentation (besides inoffical forum posts/websites) that ensures the mapping of "Disk X" (in diskpart and diskmgmt) to "PhysicalDriveX" (Windows' internal name for drives that behave similar to hard disks) is correct.
If you have any information regarding this, I'd appreciate a link to some MS documentation.
Probably something like this:
- tab/window caption:
- PhysicalDriveX (932 GiB, <ID>) and an icon identifying the type
- disk open dialog (one row per entry, 4 columns):
- PhysicalDriveX Drive/Disk-Type 932 GiB <ID>
Then again, the tab/window caption should really identify the disk quickly and without doubt, I don't think PhysicalDriveX is a good way to do that, since it's really uninformative. You often just start out with HxD, and use no other program, and want to know what drive that is without checking in another program, so PhysicalDriveX is really just for cross referencing, but not identifying. So it shouldn't take up too much caption space, abbreviating it with PDx is uncommon, and therefore possibly misleading, but I guess that could be easily explained/documented. Though it would lead to a similar issue as with diskmgmt.msc, which uses DiskX. DiskX probably matches with PhysicalDriveX, but could also be just counting the mediums/disks
, not really the drives
. So if we really are about clarity, introducing yet another name will not help, yet DiskX is really not a good name either. (Not even considering that the localized versions of Windows differ in the way they translate disk, so that no correlation with PhysicalDriveX can be made based on the name and usage of those names is inconsistent even more.)
At least the command line tool diskpart.exe seems to agree with diskmgmt.msc on naming conventions.
In conclusion, drive properties, not internal Windows names (which have almost no clear hardware correlation), should be the focus of identifying a drive (with a fixed medium). For changeable media, drive properties + specific media properties should be used. Unfortunately, media IDs are not based on media hardware, but their stored data (e.g., filesytem or partitioning), and therefore are not necessarily unique.
PhyscialDriveX/PDx/DiskX should be added, too, somehow. I am not sure if as detail, or as leading identifier. Leading identifier makes it easier to compare with other programs, such as diskpart.exe, diskmgmt.msc, get-disk (powershell), etc. But the correlation between DiskX and PhysicalDisk is not well/officially documented.
The identifying information should be clear from the window tab/caption. Additional information could be displayed in a sidebar/other window, and in the open disk dialog, easily. But the main information to clearly identify a disk should be in its name/caption.
Identifying properties of storage
- change observed in a list, when a device was attached/detached
- Age - (of manufacture) might be easier to remember than arbitrary serial numbers, and easier to identify by time of purchase or other known dates. (Especially useful if no access to drive label, and only software device lists are available, which are somewhat selfreferential, and have no correlation with the ouside world, if not known already.)
- Attachment location (physical plug location, its type such as USB/SATA, its name or number, controller type)
- Diffulties arise because a lot is virtualized or not obvious to determine for the user, especially controllers: there is no physical or visual access to that information outside of software; Also plugs get unified with USB type C.
- Device type (CD, hard disk, SD card, ...)
- Drive model and serial number
- often printed on hard disk labels, but for other devices (thumb drives, SD cards, ...) not readable without software tools, and relying on the time method mentioned above; in the last case, mostly useful to correlate disk ids in various programs
- Setups such as laptops or disk enclosures/portable disks make this less useful, since there is no easy physical access to the disk labels.
- Not clear yet if that information is queryable in a fashion that returns friendly names.
- Limited usefulness on its own, since not many manufacturers are left and therefore the name will often be the same across several drives.
- Media ids
- Are there ways to identify serial numbers of media, and not their readers/drives? This is especially useful for medias such as SD cards, or and removeable disks/discs that don't include their reader (like USB thumb drives). If yes, similar use and limitations as drive model and serial number.
Especially internal drives, in laptops, or other cumbersome to inspect setups, can only be really identified with a software device list. Additional information such as partition, contained file systems and logical drives, help a lot here.