Christian Franke wrote:
> This is a first attempt to partly emulate the Linux directory 
> /dev/disk/by-id. Useful to make sure the correct device is accessed in 
> conjunction with dd, ddrescue, fdisk, ....

Attached is the second attempt.


> The additional '*-partN' links to partitions are not yet included.

These are now included.


> This only works properly if Win32 path '\\.\PhysicalDriveN' is always 
> trivially mapped to NT path '\Device\HarddiskN\Partition0'. 
> IOCTL_STORAGE_QUERY_PROPERTY with a handle from NtOpenFile(., 
> READ_CONTROL,...) instead of CreateFile(., 0, ...) did not work with 
> all drivers. With stornvme.sys, it fails with permission denied. 
> Perhaps other permission bits are required for NtOpenFile(). Thanks 
> for any info regarding this.

According to NtQueryObject(., ObjectBasicInformation, ...), using 
NtOpenFile(., MAXIMUM_ALLOWED, ...) without admin rights sets 
GrantedAccess to 0x001200a0 
(FILE_EXECUTE|FILE_READ_ATTRIBUTES|READ_CONTROL|SYNCHRONIZE). For some 
unknown reason, NVMe drives behind stornvme.sys additionally require 
SYNCHRONIZE to use IOCTL_STORAGE_QUERY_PROPERTY. Possibly a harmless bug 
in the access check somewhere in the NVMe stack.

The disk scanning from the first patch has been reworked based on code 
borrowed from proc.cc:format_proc_partitions(). For the longer term, it 
may make sense to provide one flexible scanning function for /dev/sdXN, 
/proc/partitions and /proc/disk/by-id.


> Note that the BusType information is often not accurate. For example 
> drives behind Intel RST drivers may always be listed as 
> "raid-PRODUCT_SERIAL" even if not part of a RAID volume.
>
> The changes for the generated file devices.cc are not included in the 
> patch.


-- 
Regards,
Christian