testing: Chdir panics if not testing on the same drive as Go

[larhun]

Go version

go version go1.26.4 windows/amd64

Output of go env in your module/workspace:

set AR=ar
set CC=gcc
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_ENABLED=1
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set CXX=g++
set GCCGO=gccgo
set GO111MODULE=
set GOAMD64=v1
set GOARCH=amd64
set GOAUTH=netrc
set GOBIN=
set GOCACHE=C:\Users\***\AppData\Local\go-build
set GOCACHEPROG=
set GODEBUG=
set GOENV=C:\Users\***\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFIPS140=off
set GOFLAGS=
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\***\AppData\Local\Temp\go-build4090839346=/tmp/go-build -gno-record-gcc-switches
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMOD=Z:\***\testchdir\go.mod
set GOMODCACHE=C:\Users\***\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\***\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTELEMETRY=local
set GOTELEMETRYDIR=C:\Users\***\AppData\Roaming\go\telemetry
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.26.4
set GOWORK=
set PKG_CONFIG=pkg-config

What did you do?

On Z:\***\testchdir execute:

go mod init testchdir
mkdir chdir
cd chdir

Write the chdir_test.go file:

package chdir_test

import (
        "os"
        "testing"
)

func TestChdir_fail(t *testing.T) {
        var d = t.TempDir()
        t.Chdir(d)
}

func TestChdir_pass(t *testing.T) {
        var wd, _ = os.Getwd()
        var d = t.TempDir()
        os.Chdir(d)
        t.Cleanup(func() {
                os.Chdir(wd)
        })
}

Execute:

go test -run TestChdir_pass
go test -run TestChdir_fail

What did you see happen?

PASS result for TestChdir_pass and FAIL result for
TestChdir_fail with output:

--- FAIL: TestChdir_fail (1.90s)
    testing.go:1464: TempDir RemoveAll cleanup: unlinkat C:\Users\***\AppData\Local\Temp\TestChdir_fail1637014644\001: The process cannot access the file because it is being used by another process.
panic: testing.Chdir: chdir .: The system cannot find the path specified. [recovered, repanicked]

goroutine 7 [running]:
testing.tRunner.func1.2({0x7ff7bbdba540, 0x3fc05c6222d0})
        C:/Program Files/Go/src/testing/testing.go:1974 +0x239
testing.tRunner.func1()
        C:/Program Files/Go/src/testing/testing.go:1977 +0x349
panic({0x7ff7bbdba540?, 0x3fc05c6222d0?})
        C:/Program Files/Go/src/runtime/panic.go:860 +0x13a
testing.(*common).Chdir.func1()
        C:/Program Files/Go/src/testing/testing.go:1579 +0x94
testing.(*common).Cleanup.func1()
        C:/Program Files/Go/src/testing/testing.go:1317 +0x109
testing.(*common).runCleanup(0x3fc05c5fc400, 0x3fc05c675f48?)
        C:/Program Files/Go/src/testing/testing.go:1667 +0xea
testing.tRunner.func2()
        C:/Program Files/Go/src/testing/testing.go:2030 +0x25
testing.tRunner(0x3fc05c5fc400, 0x7ff7bbdfe010)
        C:/Program Files/Go/src/testing/testing.go:2042 +0xed
created by testing.(*T).Run in goroutine 1
        C:/Program Files/Go/src/testing/testing.go:2101 +0x4a9
exit status 2
FAIL    testchdir/chdir 2.179s

What did you expect to see?

Two PASS results, as this occurs when the testchdir module is on the C
drive instead of the Z drive.

[gabyhelp]

Related Issues

• testing: TestChdir can fail on Windows when GOROOT and TMPDIR are on different drives #69159 (closed)
• testing: robustify "relative" case in TestChdir against oldDir symlinks #75995
• os: TestFileChdir fail when GOROOT is a symbolic link #64281 (closed)
• cmd/go: test caching is broken with sub-packages when using testing.T.Chdir #79019 (closed)
• testing: TestChdir/relative failed due to symlink GOROOT path #72864 (closed)
• testing: TempDir fails when TMPDIR is a relative directory and os.Chdir() is called #67954 (closed)
• go test cache check wrong opened file when testing if user do `os.Chdir` #47305 (closed)
• testing: add TB.Chdir #62516 (closed)
• cmd/link: TestLargeText in linkbig_test.go does not look right #45406 (closed)

Related Code Changes

• path/filepath: use a temp dir in path_test.go

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

[qmuntal]

Thanks for the report. I’m trying to pin down what kind of Z: drive is involved before choosing the fix.

I tested the simpler “different drive letters” case locally using a temporary subst Z: drive, with a program that does the same cleanup primitive as testing.Chdir: open ".", chdir to a temp dir on C:, then restore with oldwd.Chdir(). That did not reproduce; it restored successfully.

So I’d like to confirm whether Z: is a mapped network drive, UNC-backed drive, subst drive, junction/symlink path, Dev Drive, or a normal local volume. Could you please share the output of these commands from the directory where the failure reproduces?

Get-Location
Get-PSDrive -PSProvider FileSystem | Format-Table Name,Root,DisplayRoot
cmd /c net use Z:
cmd /c subst
fsutil fsinfo drivetype Z:

[larhun]

I used a network mapped drive for z.

[larhun]

I accidentally closed this issue and don't have permission to reopen it. I confirm that z is a network mapped drive. I'll send the results of the checks indicated next week.

[qmuntal]

Thanks for confirming this is a mapped network drive.

I think the failure is in syscall.Fchdir rather than in testing.Chdir itself. testing.Chdir restores the old working directory by keeping an open handle to "." and later calling oldwd.Chdir(). On Windows that eventually calls GetFinalPathNameByHandleW(..., VOLUME_NAME_DOS) and then SetCurrentDirectoryW, because Windows doesn't provide a direct handle-based chdir API.

For UNC/network paths, GetFinalPathNameByHandleW can return an extended UNC path like:

\\?\UNC\server\share\dir

The current implementation removes only the leading \\?\, which turns that into:

UNC\server\share\dir

That is a relative path, not a UNC path, so SetCurrentDirectoryW can fail with “The system cannot find the path specified.”

Will send a fix soon.

[gopherbot]

Change https://go.dev/cl/796500 mentions this issue: syscall: fix Windows Fchdir with extended UNC paths

[qmuntal]

@larhun can you check if https://go-review.googlesource.com/c/go/+/796500 fixes your issue? Thanks!

[larhun]

Thank you. I will check your fix next Monday.

[larhun]

@qmuntal, this is the output of the requested checks from the directory where the failure reproduces:

PS Z:\***\***> Get-Location

Path
----
Z:\***\***

PS Z:\***\***> Get-PSDrive -PSProvider FileSystem | Format-Table Name,Root,DisplayRoot

Name Root DisplayRoot
---- ---- -----------
C    C:\
D    D:\
E    E:\
X    X:\  \\***\***
Y    Y:\  \\***\***
Z    Z:\  \\***\***

PS Z:\***\***> cmd /c net use Z:
Nome locale         Z:
Nome remoto         \\***\***
Tipo di risorsa     Disco
Stato               OK
N. aperture         12
N. connessioni      1
Esecuzione comando riuscita.

PS Z:\***\***> cmd /c subst

PS Z:\***\***> fsutil fsinfo drivetype Z:
Z: - Unità remota/di rete

[larhun]

@qmuntal, I checked https://go-review.googlesource.com/c/go/+/796500 and it fixes the current issue.