mirrors/rufus
1
0
Fork 0
mirror of https://github.com/pbatard/rufus.git synced 2025-05-23 03:06:56 -04:00
Code Issues Projects Releases Packages Wiki Activity

[core] work around a Windows bug where GetVolumePathNamesForVolumeName() can return the wrong drive letter

Browse source 
* A user is reporting that, on one of their platforms, Rufus is writing to the wrong target during the file-copy
  phase and using their existing Y: local drive instead of the drive associated to the USB, despite the fact
  that Rufus is passing the right volume name to GetVolumePathNamesForVolumeName().

* Here's the PowerShell wmic output, confirming that the volume GUID obtained by Rufus is the right one:

  DriveLetter : Y:
  DeviceId    : \\?\Volume{000349b1-17d0-69f6-c13f-f31162930600}\
  Capacity    : 118540464128
  FileSystem  : NTFS
  Label       : Y-DISK

  DriveLetter : H:
  DeviceId    : \\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\
  Capacity    : 15791824896
  FileSystem  : FAT32
  Label       : ADATA16GB

* And here's the Rufus log demonstrating that GetVolumePathNamesForVolumeName() is returning the *WRONG* letter:

  Found volume \\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\
  \\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\ is already mounted as Y: instead of H: - Will now use this target instead...

* The last line shows, without the shadow of a doubt, that we did feed "\\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\" to
  GetVolumePathNamesForVolumeName() and that this API call was successful (returned a non zero size) but ultimately returned
  the wrong letter (Y: instead of H:)...

* Therefore, Windows is BUGGY and the use of GetVolumePathNamesForVolumeName() must be avoided.
This commit is contained in:
Pete Batard 2020-08-13 14:49:34 +01:00
parent c2017ad659
commit ba406843f4
No known key found for this signature in database
GPG key ID: 38E0CF5E69EDD671
4 changed files with 17 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

2
src/format.c
View file

@ -1732,7 +1732,7 @@ DWORD WINAPI FormatThread(void* param)
}
if (drive_letters[0] == 0) {
uprintf("No drive letter was assigned...");
drive_name[0] = GetUnusedDriveLetter();
drive_name[0] = GetUnusedDriveLetter();
if (drive_name[0] == 0) {
uprintf("Could not find a suitable drive letter");
FormatStatus = ERROR_SEVERITY_ERROR|FAC(FACILITY_STORAGE)|APPERR(ERROR_CANT_ASSIGN_LETTER);