Corinna Vinschen wrote:
> Hi Christian,
>
> On Nov  5 16:45, Christian Franke wrote:
>> ...
>> Old IOCTL dropped and code simplified.
> Great.  I pushed your patch.

Thanks.


> ...
>>> Last, but not least, do you see a chance to add any other /dev/disk
>>> subdir?  by-partuuid, perhaps?
>> Possibly, but not very soon. I'm not yet sure which API functions could be
>> used.
>> Some early draft ideas:
>>
>> /dev/disk/by-partuid (Partition UUID -> device)
>>    GPT_PART_UUID -> ../../sdXN (GPT partition UUID)
>>    MBR_SERIAL-partN -> ../../sdYM (Fake UUID for MBR)
> That should only require IOCTL_DISK_GET_PARTITION_INFO_EX, I think.

Easier than expected: DRIVE_LAYOUT_INFORMATION_EX already contains 
PARTITION_INFORMATION_EX so existing scanning function could be 
enhanced. Patch attached.


>
>> /dev/disk/by-uuid (Windows Volume UUID -> device)
>>    Vol_UUID1 -> ../../sdXN  (disk volume)
>>    Vol_UUID2 -> ../../scd0  (CD/DVD drive volume)
>>    Vol_UUID3 -> /proc/sys/GLOBAL??/Volume{UUID}  (others, e.g. VeraCrypt
>> volume)
> Yeah, tricky. These are not the partition GUIDs but the filesystem
> GUIDs or serial numbers.  AFAICS, Windows filesystems (FAT*, NTFS)
> don't maintain a filesystem GUID, as, e. g., ext4 or xfs, but only
> serial numbers you can fetch via NtQueryVolumeInformationFile.
> A Linux example of that is the serial number from a FAT32 filesytem
> as the EFI boot partition in by-uuid:
>
>    lrwxrwxrwx 1 root root 10 Oct 30 10:20 DC38-0407 -> ../../sda1
>
> On second thought, maybe that's sufficient for our by-uuid emulation.
>
>> /dev/disk/by-drive (Cygwin specific: drive letter -> volume)
>>    c -> ../by-uuid/UUID (if UUID available)
>>    x -> /proc/sys/DosDevices/X: (others, e.g. Network, "mounted" Volume
>> Shadow Copy)
> Ah, good idea. That's what my extension in /proc/partition already
> provides, but a /dev/disk/by-drive sounds like a great idea.

Left for later :-)

Christian