[Bug other/115189] libiberty introduces UNC paths waking up binutils bug

["tomas.kalibera at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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?