https://sourceware.org/bugzilla/show_bug.cgi?id=31527
Simon Cook <simon.cook at embecosm dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #15460|0 |1 is obsolete| | --- Comment #14 from Simon Cook <simon.cook at embecosm dot com> --- Created attachment 15464 --> https://sourceware.org/bugzilla/attachment.cgi?id=15464&action=edit V2 Patch to fix issue, and cover more path variants I've thought about this more over the weekend, and refactored this a bit more to make it more robust, and more accurately cover relative paths when the current working directory isn't a DOS path. I've updated the comments to explain the methodology, but essentially these conversions are done based on the input string: - \\?\ -> don't touch, already in form - \\xyz\... -> \\?\UNC\xyz\... (keeping a single \ after UNC to keep it a valid input) - C:\xyz... -> \\?\C:\... - test.o, ../test.o, etc. -> check current working directory for correct prefix, such that if e.g. CWD is C:\ we end up with \\?\C:\test.o, or \\server\share\ becomes \\?\UNC\server\share\test.o I've done some more testing with a small program feeding various strings into _bfd_real_fopen both when running from local disk and network share and I think the output is now correct in all cases. I did think could this be simplified as it feels like I'm repeating myself, but the side effect of the early tests being on char strings and the later tests being on wchar_t strings as provided by Windows is a bit unfortunate. -- You are receiving this mail because: You are on the CC list for the bug.