x/sys/windows: add GetFinalPathNameByHandle

[sethkoehler]

What version of Go are you using (go version)?

$ go version
go version go1.15 windows/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\sethkoehler\AppData\Local\go-build
set GOENV=C:\Users\sethkoehler\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\sethkoehler\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\sethkoehler\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\SETHKO~1\AppData\Local\Temp\go-build711288994=/tmp/go-build -gno-record-gcc-switches

What did you do?

Went looking for GetFinalPathNameByHandle to use this as a replacement for EvalSymlinks not working with long filenames (see #40966).

What did you expect to see?

GetFinalPathNameByHandle to exist.

What did you see instead?

It was not there :)

[iwdgo]

GetFinalPathNameByHandle is available in the windows package.
A use case is in file_windows.go. which seems to fit the original purpose.
Adding an implementation to x/sys/windows does not seem to add value.

[sethkoehler]

Hmm, maybe I misunderstood (and if so, great!), but I thought I couldn't import "internal/syscall/windows" (I had gotten a 'can't find import: "internal/syscall/windows"' error message when I tried). If I should be able to import that library, then agreed that it's location in one place or the other is not important to us.

[networkimprov]

cc @alexbrainman @mattn

[ianlancetaylor]

@iwdgo This issue is about golang.org/x/sys/windows. It is not about internal/sys/windows, which is for internal standard library use and, as @sethkoehler says, can't be imported by third party packages.

[alexbrainman]

@sethkoehler if you want to add GetFinalPathNameByHandle to golang.org/x/sys/windows package, you have to do it yourself.

See https://golang.org/doc/contribute.html for instructions.

Alex

[networkimprov]

Or Constantin might be able to help, @iwdgo?

[mengzhuo]

Gobot seems not working syncing CL to this issue

https://go-review.googlesource.com/c/sys/+/264577

[sethkoehler]

Thank you for this! Out of curiosity, is there a way to see whether this will make it into Go 1.16 (my understanding is it will have just barely made it in, but I may be not properly understanding the Go release cycle).

[ianlancetaylor]

This is a change to the golang.org/x/sys repository, so it's not part of a Go release. Anybody can import it today.

[ianlancetaylor]

Also, this seems to be fixed, so closing the issue.

[sethkoehler]

Ah, that's great, thank you all!

[gopherbot]

Change https://golang.org/cl/270459 mentions this issue: windows: fix signature of GetFinalPathNameByHandle