[Bug binutils/29533] binutils 2.39 no longer works with UNC paths

[nickc at redhat dot com]

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.