0

As specified here it is possible to use absolute paths on Windows without the MAX_PATH length limitation.

However I noticed paths starting with \\?\ don't work in certain older versions of Windows.

Which version do I need to detect (e.g. with one of the functions described here) to help my software decide on using \\?\ paths?

Brecht Sanders
  • 6,215
  • 1
  • 16
  • 40
  • 1
    Does this answer your question? [How to programmatically check if the current process is long path aware on Windows?](https://stackoverflow.com/questions/40963298/how-to-programmatically-check-if-the-current-process-is-long-path-aware-on-windo). Maybe together with [this](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd), which says it is Windows 10, 1607 (as does the linked Q&A). – Christian.K Dec 20 '21 at 13:33
  • 3
    The `\\?\\` prefix only enables long-path support when calling the Unicode API. To my knowledge, this has been available for decades. Are you calling the Unicode API? – IInspectable Dec 20 '21 at 13:33
  • Also, detecting a Windows version is not how you should write feature adaptive code. Just call the API and respond to the error reported (if any). – IInspectable Dec 20 '21 at 13:59
  • @IInspectable It also works with non-Unicode API. I'm using this code in a speed-optimized directory traversal algorithm. So it's best to know in advance if it's supported. – Brecht Sanders Dec 20 '21 at 14:52
  • I can't seem to find ´RtlAreLongPathsEnabled()` or `LongPathsEnabled()` in MinGW-w64. Are thee undocumented functions? If so, how reliable is it to trust them? – Brecht Sanders Dec 20 '21 at 14:55
  • 2
    if you use `CreateFileW` with name begin with \\?\ - the long path is always supported. in any version of windows. even in xp or 2000. so you even not need check anything. of course if use native api (ie NtOpenFile) - of course always supported and also possible use relative names – RbMm Dec 20 '21 at 15:54
  • 2
    If performance is a consideration, why use the non-Unicode API? All that does is add encoding overhead in both directions. That doesn't sound conclusive, – IInspectable Dec 20 '21 at 16:01

2 Answers2

1

if you use \\?\ prefix in unicode path - the long paths is always supported in any version of windows (even win2000 and xp). question about support long paths - only affect another path types, which not begin with \\?\, such as c:\*

from Maximum Path Length Limitation

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. ... To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

usual on any individual function documentation direct stated about \\?\ prefix too (if it supported by this api - File I/O functions always support this prefix, when shell api - never)

for instance from GetFileAttributesW

To extend this limit to 32,767 wide characters, call the Unicode version of the function (GetFileAttributesW), and prepend "\\?\" to the path.

the same on CreateFileW and so on..

To extend this limit to 32,767 wide characters, use this Unicode version of the function and prepend "\\?\" to the path.

RbMm
  • 31,280
  • 3
  • 35
  • 56
0

fun is, starting Windows 10 Version 1607, you can opt-in to remove the MAX_PATH limitation in your system globally without any prefix:

https://learn.microsoft.com/de-de/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

chksr
  • 192
  • 3
  • 13