Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/go: module .lock files remain around after go command exits #29434

Closed
myitcv opened this issue Dec 27, 2018 · 3 comments
Closed

cmd/go: module .lock files remain around after go command exits #29434

myitcv opened this issue Dec 27, 2018 · 3 comments
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@myitcv
Copy link
Member

myitcv commented Dec 27, 2018

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

$ go version
go version go1.12beta1 linux/amd64

Does this issue reproduce with the latest release?

No, this is only relevant in the 1.12 (beta) series.

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

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/tmp/tmp.8thYUXnP8K"
GOPROXY=""
GORACE=""
GOROOT="/home/myitcv/gos"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/tmp/tmp.UTqhAvSYep/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build055693277=/tmp/go-build -gno-record-gcc-switches"

What did you do?

export GOPATH=$(mktemp -d)
cd $(mktemp -d)
go mod init example.com/hello
go version
command -V mtd
go get golang.org/x/tools
find $GOPATH -iname "*.lock"

What did you expect to see?

No lock files hanging around in GOPATH/pkg/mod after the go command completes.

What did you see instead?

$ find $GOPATH -name "*.lock"
/tmp/tmp.8thYUXnP8K/pkg/mod/cache/vcs/b44680b3c3708a854d4c89f55aedda0b223beb8d9e30fba969cefb5bd9c1e843.lock
/tmp/tmp.8thYUXnP8K/pkg/mod/cache/download/golang.org/x/tools/@v/v0.0.0-20181221235234-d00ac6d27372.lock
/tmp/tmp.8thYUXnP8K/pkg/mod/cache/download/golang.org/x/tools/@v/list.lock

Arguably this directory is an implementation detail and so whether these files are removed or not is essentially just that, an implementation detail, but I recall from the various CLs seeing discussion that these files should/would be removed on command exit?

cc @bcmills
@mvdan
Copy link
Member

mvdan commented Dec 28, 2018

Perhaps related - when I run go test inside go/packages with go version devel +6a64efc250 Thu Dec 27 00:07:53 2018 +0000 linux/amd64, the following files are left behind:

?? testdata/TestName_Modules/pkg/mod/cache/lock
?? testdata/TestName_ModulesDedup/pkg/mod/cache/lock

@bcmills
Copy link
Contributor

bcmills commented Jan 9, 2019

I couldn't figure out a way to remove them without either introducing race conditions, falling back to much-less-portable APIs (inotify / kqueue / FSEvents / ReadDirectoryChangesW), or both.

We did try pretty hard not to leave extraneous files in user-facing directories, but it's really a lot simpler just to leave them around in the module cache.

@bcmills bcmills added this to the Unplanned milestone Jan 9, 2019
@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 9, 2019
@bcmills
Copy link
Contributor

bcmills commented Jan 9, 2019

As far as we can tell this is harmless, so probably not worth pursuing.

@bcmills bcmills closed this as completed Jan 9, 2019
@bcmills bcmills mentioned this issue Feb 27, 2019
Open
@golang golang locked and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@myitcv @mvdan @bcmills @gopherbot