https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #8 from Tomas Kalibera ---
(In reply to Bill Zissimopoulos from comment #4)
> A more robust alternative to GetFinalPathNameByHandleW/VOLUME_NAME_DOS may
> be the following:
>
> - Use GetFinalPathNameByHandleW with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #7 from Tomas Kalibera ---
(In reply to Bill Zissimopoulos from comment #6)
> > I can reproduce the problem with "subst" and with the Windows Explorer
> > ("File/Map network drive"). I assume the is the usual way to map network
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #6 from Bill Zissimopoulos ---
> I can reproduce the problem with "subst" and with the Windows Explorer
> ("File/Map network drive"). I assume the is the usual way to map network
> drives.
The usual way to map network drives is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #5 from Tomas Kalibera ---
(In reply to Bill Zissimopoulos from comment #4)
> 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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #4 from Bill Zissimopoulos ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #3 from Tomas Kalibera ---
I hope there is a more elegant solution, but I could think of a best-effort
one. Check if the result of the normalization is a UNC path, if yes, check if
the original path started with a drive letter, if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
Richard Biener changed:
What|Removed |Added
Known to fail||13.3.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
Andrew Pinski changed:
What|Removed |Added
Host||*-*-mingw
--- Comment #1 from Andrew
