Windows: Drive via GUID

[Artoria2e5]

There's current a fairly convoluted translation from a /dev syntax to the real
.\PhysicalDrive%d syntax. Among other things, the translation blocks access to GUID identifiers, which can be useful when you are removing stuff all the time. (For example, ​ArchWiki knows the importance of UUID... on Linux.)

smartctl -a -d sat \\.\Disk{GUID}
smartctl 7.3 2022-02-28 r5338 [x86_64-w64-mingw32-w11-b22631] (sf-7.3-1)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

Smartctl open device: \\.\Disk{GUID} [SAT] failed: Invalid argument

Now unfortunately this mapping will take more than adding an escape hatch for the paths like /dev/nt/Disk{...} (or even without /dev, not sure what that can break!), because a lot of win32 support works through WMIC, which does not know about Disk GUIDs (it does know about Volume GUIDs, so that's okay until you decide to offline a disk). You will need to pry through the Object Manager, find the symlink, then find the PhysicalDrive pointing to the same place. ​https://superuser.com/a/1785654 in inverse, basically.

And the object manager isn't exactly the best documented of all places. It's ​no longer undocumented, but Microsoft retains a "this function may be altered or unavailable in the future" note. Anyway, the basics of the ​Dr. Dobbs classic still stand, and ​WinObjEx64 still exists. It's not a simple job though.

[Artoria2e5]

what these paths look like (winobjex64 screenshot)

[Christian Franke]

Makes plenty of sense. A quick test shows that \\.\Disk{GUID} could be directly opened via CreateFile without resolving the symlink. Enabling this in smartmontools would require some refactoring of current path handling.

Optionally returning paths with GUIDs from device scanning (like smartctl -d by-id --scan does under Linux) would be more complex but possible.

BTW: Cygwin (​https://cygwin.com/) also allows to browse through Windows objects as it maps these to /proc/sys:

# ls -l /proc/sys/GLOBAL\?\?/Disk*
lr--r--r-- 1 admins SYSTEM 0 May 31 17:21 '/proc/sys/GLOBAL??/Disk{..GUID..}' -> /proc/sys/Device/Harddisk1/DR1
lr--r--r-- 1 admins SYSTEM 0 May 31 17:21 '/proc/sys/GLOBAL??/Disk{..GUID..}' -> /proc/sys/Device/Harddisk2/DR2
lr--r--r-- 1 admins SYSTEM 0 May 31 17:21 '/proc/sys/GLOBAL??/Disk{..GUID..}' -> /proc/sys/Device/Harddisk0/DR0

# ls -l /proc/sys/DosDevices/{C,D,E}:
lr--r--r-- 1 admins SYSTEM 0 May 31 17:27 /proc/sys/DosDevices/C: -> /proc/sys/Device/HarddiskVolume4
lr--r--r-- 1 admins SYSTEM 0 May 31 17:27 /proc/sys/DosDevices/D: -> /proc/sys/Device/HarddiskVolume5
lr--r--r-- 1 admins SYSTEM 0 May 31 17:27 /proc/sys/DosDevices/E: -> /proc/sys/Device/HarddiskVolume7

(OT: Offers some interesting use cases like accessing files behind Volume Shadow Copies or creating images of these with dd or ddrescue)

[Artoria2e5]

Just went back to os_win32.cpp and huh. WMI is not that central after all: it's only used for disk serial and USB bus identity. A half-assed path passthru could work acceptably until there's time for more. (Less workload than NT symlink parsing, but still gotta rework a lot of open() functions.)

[Christian Franke]

Rework of device name mapping is already WIP. Device scanning of \GLOBAL??\Disk{..GUID..} could be done with NtQueryDirectoryObject().