[BUG]: RPI sees partitions from different disks as one disk

[Igbarod]

What happened?

When I try to format the MicroSD with Raspberry Pi Imager, if I have Google Drive installed, it fails because it considers Google Drive a partition of the card. I also posted the issue in the Raspberry forums and the user incognitum gave some insight on the issue.

Version

1.9.0

What host operating system were you using?

Windows

Host OS Version

22H2

Selected OS

Raspberry Pi OS Bookworm 64-bit Lite

Which Raspberry Pi Device are you using?

Raspberry Pi 4B, 400, and Compute Modules 4, 4S

What kind of storage device are you using?

microSD Card in an internal reader

OS Customisation

• Yes, I was using OS Customisation when the bug occurred.

Relevant log output

No response

[tdewey-rpi]

Including this from incognitum on the forums:

So you may want to create a github issue for that.


Technical background:

The method used there to match which drive letter belongs to which physical drive is kinda hacky.
Basically it opens each of the devices that Windows uses internally to represent a drive letter (\\.\A: \\.\B: etc.), asks: "what is your physical drive number?" and matches the results.

Catch 22 is that those physical drive numbers are not guaranteed to be globally unique, and each driver can make up its own numbers.
So the driver that handles the SD card reader can assign number 1 to the SD card reader. And the different driver that handles Google drive can also use physical drive number 1 internally...
The drivelist authors were aware of that, and as a workaround asked every drive for its type, which can be DRIVE_UNKNOWN, DRIVE_REMOVABLE, DRIVE_FIXED, DRIVE_REMOTE, DRIVE_CDROM, DRIVE_RAMDISK.
And then simply ignored drives that are not either DRIVE_REMOVABLE or DRIVE_FIXED: [https://github.com/raspberrypi/rpi-imag ... #L276-L288](https://github.com/raspberrypi/rpi-imager/blob/qml/src/dependencies/drivelist/src/windows/list.cpp#L276-L288)
But I am guessing the Google drive does advertise to be such normal drive type, so that solution does not work...

A fix may be to not only look at the physical drive number, but also query the driver name used with SetupDiGetDeviceRegistryPropertyA() and use that as additional information in addition to the drive number when matching letters to actual devices.
But will leave that up to the current Imager maintainer...```

[tdewey-rpi]

I agree, the current drivelist code leaves something to be desired - we've seen a range of interesting edge cases around virtual drives, software RAID and more exotic storage media - none of which present a good user experience.

I'm more minded to completely drop drivelist, and introduce a slimmer component that will perform an equivalent (hopefully sans undesired behaviours) function. This is aimed for Imager 2.0 at the earliest, unfortunately.