os: Getwd panics on Windows when working directory path is longer than 300

[xiaq]

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

$ go version
go version go1.20.4 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=C:\Users\xiaq\go\bin
set GOCACHE=C:\Users\xiaq\AppData\Local\go-build
set GOENV=C:\Users\xiaq\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\xiaq\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\xiaq\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.20.4
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\xiaq\on\playgo\go.mod
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\xiaq\AppData\Local\Temp\go-build2871435612=/tmp/go-build -gno-record-gcc-switches

What did you do?

Change into a directory whose absolute path is longer than 300, and call os.Getwd.

Go code to reproduce: https://go.dev/play/p/RHM2HplmUvJ

What did you expect to see?

Program should print the working directory and exit successfully.

What did you see instead?

Program panics:

panic: runtime error: slice bounds out of range [:327] with capacity 300

goroutine 1 [running]:
syscall.Getwd()
        C:/Program Files/Go/src/syscall/syscall_windows.go:511 +0xcf
os.Getwd(...)
        C:/Program Files/Go/src/os/getwd.go:24
main.main()
        C:/Users/xiaq/on/playgo/main.go:21 +0xd1
exit status 2

The cause of this bug seems quite simple: The syscall.Getwd function uses a fixed buffer size of 300 and assumes that the return value of GetCurrentDirectory never exceeds it. However, this assumption doesn't hold. According to the Win32 API doc:

If the buffer that is pointed to by lpBuffer is not large enough, the return value specifies the required size of the buffer, in characters, including the null-terminating character.

This can be fixed by comparing the return value with the size of the buffer and reallocating a larger buffer when n > len(b). This needs to be done in a loop because the working directory could be changed in parallel, so there's no guarantee that two calls of GetCurrentDirectory actually return the same value.

In case this bug has to do with the Windows version, I'm running an up-to-date Windows 11:

PS C:\Users\xiaq\on\playgo> [Environment]::OSVersion

Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.22000.0 Microsoft Windows NT 10.0.22000.0

Interestingly, the doc for long paths says that long paths are an opt-in behavior, but I don't have the documented registry value set.

[qmuntal]

Thanks for reporting this issue @xiaq, do you want to send a CL with the fix you propose?

Abou long path support, the Go runtime enables it regathless of the user choise.

[xiaq]

Thanks for reporting this issue @xiaq, do you want to send a CL with the fix you propose?

I can do that. I haven't contributed to Go before so it will take a bit of time for me to figure out the process.

Abou long path support, the Go runtime enables it regathless of the user choise.

Aha. The Win32 doc says that the behavior requires opt-in from both the process and the user's registry, but I suppose Go forces it to be enabled by poking directly into the PEB.

[qmuntal]

I can do that. I haven't contributed to Go before so it will take a bit of time for me to figure out the process.

Great! You can follow the steps described at https://go.dev/doc/contribute.

[gopherbot]

Change https://go.dev/cl/502415 mentions this issue: syscall: Fix Getwd on Windows to correctly handle long paths.