curl_multibyte: support Windows paths longer than MAX_PATH #13522
Conversation
|
Merge conflicts. Any plans to move forward on this? |
|
It is still necessary for our use case. @jay can you take a look at the conflicts? |
|
I fixed the conflicts. Also I reversed and took @nmoinvaz's suggestion to use 'goto cleanup' instead of 'goto error' to eliminate any confusion in the logic. Though I don't foresee this PR causing any problems I'm going to wait until the next feature window to land it. |
- Add a helper function for the Windows file wrapper functions that will normalize a long path (or a filename in a long path) and add the prefix `\\?\` so that Windows will access the file. Prior to this change if a filename (when normalized internally by Windows to its full path) or a path was longer than MAX_PATH (260) then Windows would not open the path, unless it was already normalized by the user and had the `\\?\` prefix prepended. The `\\?\` prefix could not be passed to file:// so for example something like file://c:/foo/bar/filename255chars could not be opened prior to this change. There's some code in tool_doswin that will need to be modified as well to further remove MAX_PATH (aka PATH_MAX) limitation. Ref: curl#8361 Ref: curl#13512 Ref: https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats Ref: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation Closes #xxxx
2250ebf
to
66d5128
Compare
|
@bagder is it possible for this to be merged for the next release? Thanks. |
|
Ok I wasn't sure. I just wanted to make sure it wasn't abandoned because you told us on another PR that you closed it because we didn't push hard enough for it. Thanks! |
|
This is held up by a CI failure in a Windows UWP job that I haven't had time to reproduce, apparently there is a missing GetFullPathNameW but according to the doc it exists in UWP apps The earliest this will be in a release is 2 months from now because it's not going in the patch release coming this Wednesday |
|
\\?\so that Windows will access the file.Prior to this change if a filename (when normalized internally by Windows to its full path) or a path was longer than MAX_PATH (260) then Windows would not open the path, unless it was already normalized by the user and had the
\\?\prefix prepended.The
\\?\prefix could not be passed to file:// so for example something like file://c:/foo/bar/filename255chars could not be opened prior to this change.There's some code in tool_doswin that will need to be modified as well to further remove MAX_PATH (aka PATH_MAX) limitation.
Ref: #8361
Ref: #13512
Ref: https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats
Ref: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
Closes #xxxx