Opened 9 months ago

Last modified 9 months ago

#1729 accepted enhancement

Windows: Drive via GUID

Reported by: Artoria2e5 Owned by: Christian Franke
Priority: minor Milestone: unscheduled
Component: all Version: 7.3
Keywords: windows Cc:


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,

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. 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.

Attachments (1)

Screenshot 2023-05-31 143126.png (113.3 KB ) - added by Artoria2e5 9 months ago.
what these paths look like (winobjex64 screenshot)

Download all attachments as: .zip

Change History (4)

by Artoria2e5, 9 months ago

what these paths look like (winobjex64 screenshot)

comment:1 by Christian Franke, 9 months ago

Keywords: windows added
Milestone: unscheduled

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 ( 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)

comment:2 by Artoria2e5, 9 months ago

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.)

comment:3 by Christian Franke, 9 months ago

Owner: set to Christian Franke
Status: newaccepted

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

Note: See TracTickets for help on using tickets.