https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #8 from Tomas Kalibera <tomas.kalibera at gmail dot com> --- (In reply to Bill Zissimopoulos from comment #4) > A more robust alternative to GetFinalPathNameByHandleW/VOLUME_NAME_DOS may > be the following: > > - Use GetFinalPathNameByHandleW with VOLUME_NAME_NORMALIZED|VOLUME_NAME_NT. > > - Enumerate all available drives for the current process using > GetLogicalDrives. > > - For each logical drive use QueryDosDeviceW to see if the returned prefix > matches the NT namespace prefix returned by the earlier call to > GetFinalPathNameByHandleW. > > For an example of this approach see the chromium code here: > > https://chromium.googlesource.com/chromium/src/base/+/master/files/ > file_util_win.cc#828 > > (See functions NormalizeFilePath and DevicePathToDriveLetterPath.) I am not sure how this would work. On my system, I get a number of different NT namespace prefixes from QueryDosDevice: (1) \??\UNC\tsclient\share (2) \??\UNC\192.168.0.45\share (3) \Device\LanmanRedirector\;Y:0000000001189cc1\192.168.0.45\share (4) \Device\RdpDr\;Z:2\tsclient\share the forms of (1),(2) are with "subst". The form of (3) is when using Explorer on a real samba drive (also "net use"). The form of (4) is when using Explorer on an RDP share (also "net use"). But, GetFinalPathNameByHandle() returns prefixes in a yet different form: (A) /Device/Mup/192.168.0.45/share (B) /Device/Mup/tsclient/share where (A) is for a real samba drive and (B) for the RDP share. So, simply matching the prefix (whether the result of QueryDosDevice() is a prefix of the result of GetFinalPathNameByHandle) probably wouldn't work?
