Use os.Open for Windows realpath to handle long paths

[jakebailey]

My hand-written open function doesn't handle long paths, relying on the SEH bit Go normally sets. But, that bit is undocumented and seemingly isn't approved for using in releases, and isn't set in artifacts built by the Go fork used by Microsoft.

Rather than use CreateFile directly, use os.Open instead, which will handle long paths. I didn't do this initially because I thought it didn't work on directories, but it actually has worked since https://go.dev/cl/405275 a long time ago.

I don't have a test for this because I can't seem to make a link with long enough paths in the tests... ☹️

cc @qmuntal

[Copilot]

Pull Request Overview

This PR updates the Windows realpath implementation to use os.Open instead of a custom openMetadata function that relies on undocumented SEH bits.

• Replaces CreateFile-based openMetadata with os.Open.
• Updates resource clean-up using f.Close() and converts the file descriptor with windows.Handle.

Comments suppressed due to low confidence (1)

internal/vfs/osvfs/realpath_windows.go:14

• [nitpick] Consider renaming the variable 'f' to a more descriptive name such as 'file' to improve code clarity.

f, err := os.Open(path)

[qmuntal]

The slow down comes from the fact that os.Open opens the file with the GENERIC_READ access, while you were previously using FILE_ANY_ACCESS(0). Note that the name is misleading, as passing 0 to the desired access is equivalent to just passing FILE_READ_ATTRIBUTES. When CreateFileW sees that the only desired access is FILE_READ_ATTRIBUTES, then it can open the file much faster, as it doesn't have to prepare it for doing I/O.

The problem is that the "just reading the attributes" access right does not map well with any Unix concept, so using just this access is not well supported by the os, it being Unix-centric. On the other hand, you can stretch the implementation by calling os.OpenFile(name, 3, 0) instead of os.Open(name). That would do exactly what you want: the access passed to CreateFileW will be 0, as the access mode 3 doesn't match any of the mapped accesses in here: https://github.com/golang/go/blob/a2fbb50322e716f75e9c4707afd2de725a95e14b/src/syscall/syscall_windows.go#L373-L381. On my computer, this trick opens files 3 times faster.

[jakebailey]

Hm, unfortunately opening with flag=3 causes tests to fail due to EISDIR, which I assume is because FILE_FLAG_BACKUP_SEMANTICS isn't getting set.

[jakebailey]

Maybe I'll just use my helper for len(path) < 248 and then use plain os.Open for anything longer.

[qmuntal]

Maybe I'll just use my helper for len(path) < 248 and then use plain os.Open for anything longer.

That will only work for absolute paths. You can have a relative path that is just one character long and still hit the long path limit if the working directory is 247 characters or more.

Do you normally pass relative paths to realpath? If they are a minority, then you can always convert them to absolute before doing the length check, although that conversion is not free.

[jakebailey]

They won't be relative; this FS abstraction is always absolute.