https://sourceware.org/bugzilla/show_bug.cgi?id=29533
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nickc at redhat dot com
--- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
(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?
--
You are receiving this mail because:
You are on the CC list for the bug.
