go: cmd/go: fails when main module is in a 9P network share on Windows Subsystem for Linux

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

$ go version
go version go1.14 windows/amd64

Does this issue reproduce with the latest release?

It is the last release

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

go env Output

$ go env
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\a\AppData\Local\go-build
set GOENV=C:\Users\a\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS= -mod=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\a\go
set GOPRIVATE=
set GOPROXY=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=Z:\home\a\go\graph\go.mod
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 -fmessage-length=0 -fdebug-prefix-map=C:\Users\a\AppData\Local\Temp\go-build115528494=/tmp/go-build -gno-record-gcc-switches

What did you do?

I’m using Windows Subsystem for Linux 2 and I access my files using a network driver. I tried to use go mod init in a new project and got this error :

a@Hackintosh-Windows MINGW64 /z/home/a/go/graph
$ go mod init graph
go: creating new go.mod: module graph
go: updating go.mod: Lock Z:\home\a\go\graph\go.mod: Fonction incorrecte.

(Fonction incorrecte means incorrect/invalid function)

Then i tried to create it by end with the content :

module graph

go 1.14

Running go list -m (or any command requiring this file actually) gives me this error : go: RLock Z:\home\a\go\graph\go.mod: Fonction incorrecte.

What did you expect to see?

my go.mod file created.

What did you see instead?

An error about Lock/RLock.

More information:

After reinstalling go 1.13.8, i had everything working back.

About this issue

Original URL
State: open
Created 4 years ago
Comments: 24 (13 by maintainers)

Commits related to this issue

cmd/go/internal/lockedfile: ignore errors if locks are not supported Some file systems do not support file locking. Ignore lock errors in these environments. I used the already implemented IsNotSuppo... — committed to kamijin-fanta/go by kamijin-fanta 4 years ago

Most upvoted comments

Many more people are in need of this. Having an option to disable the file locking would make it work

+28

jaytaph on Oct 9, 2020

Can the support of WSL2 be considered or included into roadmap?

WSL2 is becoming a popular platform as it soothes many pains of development under Windows.

+11

artsafin on Jun 2, 2020

That said, I thought the goal of WSL was to permit running GNU/Linux programs on Windows. It ought to work to run GOOS=linux go build to get a GNU/Linux binary and then run that binary under WSL.

The problem here is when your code lives within the WSL2 VM, but you’re working on it via the \wsl$ network share in your IDE / toolchain. A lot of us have adopted this since it allows us to code in Windows, but do all testing / verification in Linux.

The go binary fails to lock the needed .mod or .sum files when called with the wsl$ network path and subsequently fails. I suspect this will probably happen with all network shares in Windows.

Wintereise on Jun 9, 2020

@kamijin-fanta, the tests in lockedfile_test.go and transform_test.go should run on Plan 9 the same as on every other platform.

There is an additional integration test in mod_concurrent.txt that I believe also runs on Plan 9.

bcmills on Dec 4, 2020