[PATCH] Cygwin: Add /dev/disk/by-id symlinks

[Corinna Vinschen]

On Nov  3 18:54, Christian Franke wrote:
> Corinna Vinschen wrote:
> > On Nov  3 17:27, Corinna Vinschen wrote:
> > > On Nov  3 17:09, Christian Franke wrote:
> > > > Unlike (S)ATA and NVMe, the serial number
> > > > is not available for free in the device identify data block but requires an
> > > > extra command (SCSI INQUIRY of VPD page 0x80). This might not be supported
> > > > by the emulated controller or Windows does not use this command.
> > > AFAICS, only the data from STORAGE_DEVICE_ID_DESCRIPTOR is available
> > > which is equivalent to the data from VPD page 0x83.  As you can see,
> > > it's part of the STORAGE_DEVICE_UNIQUE_IDENTIFIER data.  The data
> > > returned for the VirtIo device is the identifier string "\x01\x00",
> > > which is a bit underwhelming.
> > > 
> > > Would be great if we would learn how to access page 0x80...
> > Uhm...
> > 
> > MSDN claims:
> > 
> >    If the storage device is SCSI-compliant, the port driver attempts to
> >    extract the serial number from the optional Unit Serial Number page
> >    (page 0x80) of the VPD.
> > 
> > Now I'm puzzled.
> 
> A quick test with a Debian 12 VM in VirtualBox with many virtual
> controllers+drives shows the same problem:
> Entries in /dev/disk/by-id appear only for virtual disks behind emulated
> SATA and NVMe controllers, but not for SCSI and SAS controllers.
> A test with "smartctl -i ..." with SCSI/SAS devices doesn't print a serial
> number. In debug mode it prints "Vital Product Data (VPD) INQUIRY failed..."
> and other messages that suggest limited/buggy support of optional SCSI
> commands.
> 
> If a Win11 PE (from install ISO) is run in same VM, the
> STORAGE_DEVICE_DESCRIPTOR only provides the serial number for SATA (NVMe
> drives not detected), but not for SCSI.
> 
> Conclusion: The behavior of the current patch is compatible with Linux :-)

Ok, but with the DUID we have a workaround which makes it  work even
better than on Linux, so it would begreat if we used it, unless we find
out where the UUID in "\GLOBAL??\Disk{<UUID>} comes from...

Given the size of the STORAGE_DEVICE_UNIQUE_IDENTIFIER struct, we could
even contemplate a 128 bit hash, just to be on the safe side.


Corinna