os: investigate dropping support for pre-long-path Windows

[neild]

On Windows, the os package includes some trickery to enable support for long paths on older versions of Windows. The fixLongPath function rewrites longer paths to contain a \\?\ prefix, which "tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system." (https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces)

The \\?\ prefix can have effects other than just making a longer path work. For example, Mkdir(`\\?\c:\foo `) will create a directory "foo " with a trailing space, while Mkdir(`c:\foo `) will strip the space and create "foo".

Newer versions of Windows optionally support long paths directly. On Windows 10.0 with a build ID of 15063 and higher, we skip the \\?\ workaround: https://go.googlesource.com/go/+/refs/tags/go1.23.0/src/runtime/os_windows.go#450

Interestingly, the Windows documentation indicates that long paths should be supported on 10.0.1607 and higher
(https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later), and 1607 is build id 14393 (https://learn.microsoft.com/en-us/windows/release-health/release-information).

I don't know why we're checking for a build ID of 15063 instead of 14393.

https://go.dev/wiki/MinimumRequirements#windowswindows says that the supported Windows versions are Windows 10 and higher or Windows Server 2016 and higher.

I don't know what versions of Windows Server 2016 support long paths.

Do we still support any versions of Windows that don't have long path support? Can we just drop the \\?\ workaround entirely?

/cc @qmuntal

[gabyhelp]

Related Issues and Documentation

• os: use extended-length paths on Windows when possible
• proposal: runtime: don't enable process-wide long path support on Windows #66560
• golang not supporting windows paths over 255 characters #14495 (closed)
• os.Lstat & os.OpenFile fail at handling long paths on Windows #15208 (closed)
• os: on Windows, don't fix long paths that aren't long
• os: make MkdirAll support path in extended-length form
• os: on Windows, implement fixLongPath also for relative paths
• path/filepath: EvalSymlinks doesn't work for Windows long filenames #40966 (closed)
• runtime: support long paths without fixup on Windows 10 >= 1607
• syscall, os: Chmod doesn't support long paths on Windows #20829 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

Perhaps related to #66560.

[qmuntal]

Yep, this proposal is the opposite of #66560. A summary of what I said in there:

• Windows does not support enabling long path support at runtime. To do it right, one must embed a manifest to the binary stating long path support and also opt-in to long path support system-wide via a registry setting. See https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later for the exact steps to follow. Note that prepending \\?\ to the path is also a documented alternative.
• Go uses an undocumented hack (modify the TEB) to enable long path support at runtime. It is the sole big framework that does so. If you use Python, C#, Node, Rust, etc., you should follow the official way to enable long path support.
• The Windows security team at Microsoft opinion about Go's hack is that we shouldn't be doing it. It is not covered by the Windows back compat policy and any use of undocumented API should be treated as a security issue, as it will eventually result in unexpected behavior. They will not hesitate to break Go if there is any vulnerability that requires modifying how it enables long path support,
• The Microsoft Go fork that my team maintains has removed this hack to be in compliance with the aforementioned policy.
• I'm working with the Windows security team to find a way to enable long path support without having to modify the registry, just by using the embedded manifest, but the chances of this happening soon are quite low.

In a nutshell, I'm opposed to this proposal, it goes in the opposite direction of what I think we should be doing.