| Summary: | binutils 2.39 no longer works with UNC paths | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Brecht Sanders <brecht> |
| Component: | binutils | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | nickc, tromey |
| Priority: | P2 | ||
| Version: | 2.39 | ||
| Target Milestone: | --- | ||
| URL: | https://github.com/brechtsanders/winlibs_mingw/issues/112 | ||
| Host: | x86_64-w64-mingw32 | Target: | x86_64-w64-mingw32 |
| Build: | Last reconfirmed: | ||
|
Description
Brecht Sanders
2022-08-28 13:57:59 UTC
(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? |