https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #4 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> --- The lrealpath function on Windows uses the GetFinalPathNameByHandleW function with the VOLUME_NAME_DOS flag. I do not currently have access to a Windows system with dev tools, but my recollection is that the VOLUME_NAME_DOS flag should be sufficient to correctly find the DOS drive in most cases including network drives. Unfortunately GetFinalPathNameByHandleW does not work with drives created with the DefineDosDeviceW API (e.g. drives created using the SUBST utility). How are people who stumble on this bug create their drives? 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.)
