In https://sourceware.org/bugzilla/show_bug.cgi?id=25713 code was changed in _bfd_real_fopen() in bfd/bfdio.c to handle long path names in Windows. This was done by prepending pefix "\\?\" to the path. Unfortunately this breaks using UNC network paths (\\server\share). Looking at https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry it probably also breaks relative paths and paths containing . or .. as references to the current/parent directory. So it looks like the patch from https://sourceware.org/bugzilla/show_bug.cgi?id=25713 is incomplete and should be modified to at least also support UNC paths. I'm not the only one with this issue, see also: https://github.com/brechtsanders/winlibs_mingw/issues/112 Also, from a performance point of view, I don't see the point in converting the path to UTF16 and using the wide path (as done in _bfd_real_fopen() in bfd/bfdio.c). Is this necessary or is there any added benefit in doing so?
(In reply to Brecht Sanders from comment #0) Hi Brecht, Sorry for not replying to this PR sooner. > Unfortunately this breaks using UNC network paths (\\server\share). So are you saying that if the path provided starts with "\\" then the code in bfd/bfdio.c:_bfd_real_fopen() should not a "\\?\" prefix ? Or should it use the prefix "\\?\UNC\" instead ? > Looking at > https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path- > limitation?tabs=registry it probably also breaks relative paths and paths > containing . or .. as references to the current/parent directory. I thought that the whole point of the patch for PR 25713 was to ensure that the code could cope with long paths, including those that contain . and/or .. I am no expert on Windows file naming conventions, so I am going to rely upon the advice of others. Do you have a patch that could fix this problem ? Cheers Nick > So it looks like the patch from > https://sourceware.org/bugzilla/show_bug.cgi?id=25713 is incomplete and > should be modified to at least also support UNC paths. > > I'm not the only one with this issue, see also: > https://github.com/brechtsanders/winlibs_mingw/issues/112 > > Also, from a performance point of view, I don't see the point in converting > the path to UTF16 and using the wide path (as done in _bfd_real_fopen() in > bfd/bfdio.c). Is this necessary or is there any added benefit in doing so?
I think this is a dup of bug#31527