Match drive letter with physical disk
-
I am trying to automate our backup procedure at work. For the most part it works great, unless the drive configuration changes. Each machine has a dedicated backup drive, but when the backup runs in Windows PE 2.0, this drive does not have the same letter for each machine. Usually this letter is always the same on a per-machine basis, but if for instance someone accidentally leaves a USB stick plugged in when the backup runs, the drive letters might change (found this out when the last backup ran...ended up backing up to the user's primary disk). So I'm trying to find a reliable, consistent way to always pick the right drive letter for the backup. I've tried using WMI to get the hard disk serial number (Win32_PhysicalDisk, as suggested here[^]), but not all drives have one (mine, in fact). I would try matching by volume label, but it's not the same for everyone (one machine has both the primary and backup disks labeled "Local Disk", so that won't work so well). I know I could change the volume labels to work for me, but on the off chance someone else changes the label later, it would break. I can't use any .NET solutions because Windows PE simply doesn't support .NET. I also haven't been able to get any native C or C++ solutions to work because I can't get the C++ runtime to install in PE. I did find a package that's supposed to work, but it didn't for me, and I followed on the directions exactly. Any recommendations? I'm about to resort to the changing all the volume labels and just tell everyone "Don't touch this!" but as I said, I'd like a more reliable solution if possible. Thanks, Dybs
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
-
I am trying to automate our backup procedure at work. For the most part it works great, unless the drive configuration changes. Each machine has a dedicated backup drive, but when the backup runs in Windows PE 2.0, this drive does not have the same letter for each machine. Usually this letter is always the same on a per-machine basis, but if for instance someone accidentally leaves a USB stick plugged in when the backup runs, the drive letters might change (found this out when the last backup ran...ended up backing up to the user's primary disk). So I'm trying to find a reliable, consistent way to always pick the right drive letter for the backup. I've tried using WMI to get the hard disk serial number (Win32_PhysicalDisk, as suggested here[^]), but not all drives have one (mine, in fact). I would try matching by volume label, but it's not the same for everyone (one machine has both the primary and backup disks labeled "Local Disk", so that won't work so well). I know I could change the volume labels to work for me, but on the off chance someone else changes the label later, it would break. I can't use any .NET solutions because Windows PE simply doesn't support .NET. I also haven't been able to get any native C or C++ solutions to work because I can't get the C++ runtime to install in PE. I did find a package that's supposed to work, but it didn't for me, and I followed on the directions exactly. Any recommendations? I'm about to resort to the changing all the volume labels and just tell everyone "Don't touch this!" but as I said, I'd like a more reliable solution if possible. Thanks, Dybs
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
This is what I did on one similar occasion: - keep a file with a special name on the backup device/partition (e.g.
__THIS_IS_THE_BACKUP_DEVICE__.txt); - get the list of all drive letters; - scan each of them for the specially named file, use the (first) one found. The advantage is it does not depend on particularities of configurations, Windows versions, etc. The main disadvantage is you might have more than one matching partition (in which case you could use the first one, or ask the user). :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
I am trying to automate our backup procedure at work. For the most part it works great, unless the drive configuration changes. Each machine has a dedicated backup drive, but when the backup runs in Windows PE 2.0, this drive does not have the same letter for each machine. Usually this letter is always the same on a per-machine basis, but if for instance someone accidentally leaves a USB stick plugged in when the backup runs, the drive letters might change (found this out when the last backup ran...ended up backing up to the user's primary disk). So I'm trying to find a reliable, consistent way to always pick the right drive letter for the backup. I've tried using WMI to get the hard disk serial number (Win32_PhysicalDisk, as suggested here[^]), but not all drives have one (mine, in fact). I would try matching by volume label, but it's not the same for everyone (one machine has both the primary and backup disks labeled "Local Disk", so that won't work so well). I know I could change the volume labels to work for me, but on the off chance someone else changes the label later, it would break. I can't use any .NET solutions because Windows PE simply doesn't support .NET. I also haven't been able to get any native C or C++ solutions to work because I can't get the C++ runtime to install in PE. I did find a package that's supposed to work, but it didn't for me, and I followed on the directions exactly. Any recommendations? I'm about to resort to the changing all the volume labels and just tell everyone "Don't touch this!" but as I said, I'd like a more reliable solution if possible. Thanks, Dybs
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
dybs wrote:
I can't get the C++ runtime to install in PE
You do not need to install any C++ runtime. You can change the compiler settings in such a way so that it produces a static build which has no dynamic ATL/MFC/CRT dependencies. For translating a drive letter to a physical disk number: Translating logical drives to physical[^] But I would argue that this is also not reliable... Im not positive but I believe the physical disk number can change too upon reboot with muliple external USB drives connected. To be honest... the solution Luc gave you will work reliably. Theres no reason to make it complicated. If you for whatever reason do want to make it complicated let me know and I will give you two lengthy and complex ways to find the backup drive. Best Wishes, -David Delaune Edit: Removed the root domain from the FQDN.
-
This is what I did on one similar occasion: - keep a file with a special name on the backup device/partition (e.g.
__THIS_IS_THE_BACKUP_DEVICE__.txt); - get the list of all drive letters; - scan each of them for the specially named file, use the (first) one found. The advantage is it does not depend on particularities of configurations, Windows versions, etc. The main disadvantage is you might have more than one matching partition (in which case you could use the first one, or ask the user). :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
Thanks Luc. I think, as Randor mentioned, I was trying to make this more complicated than it should be. With the way our setup is, I can be sure that only one partition on a given machine will have the specially-named file. Thanks!
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
-
dybs wrote:
I can't get the C++ runtime to install in PE
You do not need to install any C++ runtime. You can change the compiler settings in such a way so that it produces a static build which has no dynamic ATL/MFC/CRT dependencies. For translating a drive letter to a physical disk number: Translating logical drives to physical[^] But I would argue that this is also not reliable... Im not positive but I believe the physical disk number can change too upon reboot with muliple external USB drives connected. To be honest... the solution Luc gave you will work reliably. Theres no reason to make it complicated. If you for whatever reason do want to make it complicated let me know and I will give you two lengthy and complex ways to find the backup drive. Best Wishes, -David Delaune Edit: Removed the root domain from the FQDN.
David, Thanks for the suggestions. I'll be going with Luc's solution, but that's good to know about the compiler settings. BTW, the link you posted gave me a 404 error. Even though I won't be going the complicated route, I'm curious what your two "lengthy and complex" ways are, just to improve on my understanding of things. Brandon
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
-
Thanks Luc. I think, as Randor mentioned, I was trying to make this more complicated than it should be. With the way our setup is, I can be sure that only one partition on a given machine will have the specially-named file. Thanks!
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
you're welcome. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
David, Thanks for the suggestions. I'll be going with Luc's solution, but that's good to know about the compiler settings. BTW, the link you posted gave me a 404 error. Even though I won't be going the complicated route, I'm curious what your two "lengthy and complex" ways are, just to improve on my understanding of things. Brandon
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
dybs wrote:
BTW, the link you posted gave me a 404 error.
Sorry about that...I have a bad habit of adding an additional DOT at the end of my domain names. It seems I am one of the only Unix guys dinosaurs left on the planet who remembers the FQDN RFC standards. I do not know why major OS/webserver and browser vendors fail to follow the standard. Trailing Dots in Domain Names[^] Thanks for the heads-up... after this comment I will go check my older posts to see if I did it anywhere else.
dybs wrote:
Even though I won't be going the complicated route, I'm curious what your two "lengthy and complex" ways are, just to improve on my understanding of things.
The unsupported API method: Everything you need is inside the device instance id so you can call SetupDiEnumDeviceInfo and enumerate disk Drive class[^] hardware and call SetupDiGetDeviceInstanceId for each drive found. Now you can attempt to open the device and send a IOCTL_STORAGE_GET_DEVICE_NUMBER with DeviceIOControl. The hacktastic registry method: If you wanted to avoid undocumented/unsupported API calls you could find the backup device by reading the following registry keys: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR If you look closely at the REG_BINARY data in the MountedDevices key you will find that it actually contains a unicode string with a unique identifier matching a subkey of the USBSTOR key. I believe you would need to read the REG_BINARY data in the MountedDevices key into a wide string and and parse for USBSTOR. One you find a qualifying key containing USBSTOR you tokenize it using the pound character #. If the third token matches the key from the USBSTOR key then the name of the key is the drive letter. Here is an example straight from my registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\Disk&Ven_Lexar&Prod_JD_Lightning_II&Rev_1100\106A1D04160224220907&0
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\**DosDevices\I:"=**hex:5f,00,3f,00,3
-
dybs wrote:
BTW, the link you posted gave me a 404 error.
Sorry about that...I have a bad habit of adding an additional DOT at the end of my domain names. It seems I am one of the only Unix guys dinosaurs left on the planet who remembers the FQDN RFC standards. I do not know why major OS/webserver and browser vendors fail to follow the standard. Trailing Dots in Domain Names[^] Thanks for the heads-up... after this comment I will go check my older posts to see if I did it anywhere else.
dybs wrote:
Even though I won't be going the complicated route, I'm curious what your two "lengthy and complex" ways are, just to improve on my understanding of things.
The unsupported API method: Everything you need is inside the device instance id so you can call SetupDiEnumDeviceInfo and enumerate disk Drive class[^] hardware and call SetupDiGetDeviceInstanceId for each drive found. Now you can attempt to open the device and send a IOCTL_STORAGE_GET_DEVICE_NUMBER with DeviceIOControl. The hacktastic registry method: If you wanted to avoid undocumented/unsupported API calls you could find the backup device by reading the following registry keys: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR If you look closely at the REG_BINARY data in the MountedDevices key you will find that it actually contains a unicode string with a unique identifier matching a subkey of the USBSTOR key. I believe you would need to read the REG_BINARY data in the MountedDevices key into a wide string and and parse for USBSTOR. One you find a qualifying key containing USBSTOR you tokenize it using the pound character #. If the third token matches the key from the USBSTOR key then the name of the key is the drive letter. Here is an example straight from my registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\Disk&Ven_Lexar&Prod_JD_Lightning_II&Rev_1100\106A1D04160224220907&0
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\**DosDevices\I:"=**hex:5f,00,3f,00,3
Randor, Thanks for the detailed info! In my case, though, the "hacktastic registry" solution would not work because the backup drive is a removable SATA drive, not USB. Still, good to know. FYI, looking in my own registry, I only had the USBSTOR data in one pair of keys, both pointing to the same drive:
\??\Volume{9243114d-2fd5-11df-aac5-00e04cf116c3}
and
\DosDevices\G:Dybs
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen