cmd/go: 'Access is denied' when renaming module cache directory

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

13.6

Does this issue reproduce with the latest release?

yes

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

Window 10, intel

go env Output

$ go env

What did you do?

I had a mod file which is 1.13

When I run go build, it download the dependency, however, it end with error like this. e.g.

cannot load golang.org/x/net/html: rename C:\Users\502380\go\pkg\mod\golang.org\x\net@v0.0.0-20190620200207-3b0461eec859.tmp-839788141 C:\Users\502380\go\pkg\mod\golang.org\x\net@v0.0.0-20190620200207-3b0461eec859:

What did you expect to see?

build should successful without any error.

What did you see instead?

#This is running in jetbrain goland

go: extracting golang.org/x/net v0.0.0-20190620200207-3b0461eec859
build command-line-arguments: cannot load golang.org/x/net/html: rename C:\Users\502380\go\pkg\mod\golang.org\x\net@v0.0.0-20190620200207-3b0461eec859.tmp-839788141 C:\Users\502380\go\pkg\mod\golang.org\x\net@v0.0.0-20190620200207-3b0461eec859: Access is denied.

@kiwionly

@kiwionly Could you provide an example of the code that produced the error, preferably as a Go playground link?

Seems like the same issue as microsoft/vscode-go#2897. We've never been able to reproduce this.

Could you post a listing of the directory C:\Users\502380\go\pkg\mod\golang.org\x\?
Are you able to reproduce this or did it just happen once? How about after clearing the module cache with go clean -modcache?

@cagedmantis

@cagedmantis @jayconrod I am doing go build with module using Jetbrain Goland, some how command prompt also able to produce the error.

Note that my application contain a lot of dependency, and i need to rerun > go build , sometime it success, sometime it will fail with error message below ( depend on the package, some package will have issue, then I run go build again, no more issue/)

Here is the error when running in command prompt using go get, but actually the error is same ( except go build is loading a lot of dependency compare to go get below, but github.com/go-playground/locales is the one that always fail )

C:\Users\502380\GolandProjects\myproject>go get github.com/go-playground/universal-translator
go: finding github.com/go-playground/universal-translator v0.17.0
go: downloading github.com/go-playground/universal-translator v0.17.0
go: extracting github.com/go-playground/universal-translator v0.17.0
go: downloading github.com/go-playground/locales v0.13.0
go: extracting github.com/go-playground/locales v0.13.0
..\..\go\pkg\mod\github.com\go-playground\universal-translator@v0.17.0\errors.go:7:2: rename C:\Users\502380\go\pkg\mod\github.com\go-playground\locales@v0.13.0.tmp-022886503
 C:\Users\502380\go\pkg\mod\github.com\go-playground\locales@v0.13.0: Access is denied.

@jstarks

For the rename of that directory, we use a separate lockfile:

go/src/cmd/go/internal/modfetch/fetch.go

Line 76 in 6718cb6

unlock, err := lockVersion(mod)

go/src/cmd/go/internal/modfetch/fetch.go

Lines 82 to 83 in 6718cb6

    
           // Check whether the directory was populated while we were waiting on the lock. 
        
           fi, err = os.Stat(dir)

go/src/cmd/go/internal/modfetch/fetch.go

Line 122 in 6718cb6

if err := os.Rename(tmpDir, dir); err != nil {

So the only possibilities I can see for this failure are:

A bug in our lockedfile.Mutex or os.Rename implementation is causing the file-locks to not actually synchronize the other I/O operations.
Something (perhaps Goland, or perhaps an antivirus scanner?) is accessing one or both of the directories to be renamed without holding the associated file lock.
A bug in the Windows kernel or filesystem implementation is causing the file-locks to not actually synchronize the other I/O operations.

Of course, it is also possible that I have missed something.

For cause (1), we should fix our implementation.

For cause (2) or (3), we should ensure that a bug is filed against the appropriate other project, and then we could perhaps use robustio.Rename instead of os.Rename if we believe that will help. However, I would want some way to empirically reproduce and measure the problem and the mitigation to verify that it actually does help.

CC @jstarks @alexbrainman @zx2c4 @networkimprov in case they have any insights into how to debug this.

@kiwionly

@kiwionly do u use Ubuntu 18.04 on windows 10 ?
do u use Mcafee Endpoint Security ?
if so just search and find ubuntu1804.exe in your system
then right click ubuntu1804.exe-> properties -> compatibility（second tab） -> Setting（select run as administration ） ,then click Application (A) , all is ok ;

if it still build fail ,please click security tab ， and click Advaced(V)
make sure your account access has Complete control ,default all allow is TrustedInstaller user ,this will prevented by Mcafee ;

wish it helped all who met this err ,I had troubled by it for months ;

@kiwionly

@kiwionly do u use Ubuntu 18.04 on windows 10 ?
do u use Mcafee Endpoint Security ?
if so just search and find ubuntu1804.exe in your system
then right click ubuntu1804.exe-> properties -> compatibility（second tab） -> Setting（select run as administration ） ,then click Application (A) , all is ok ;

if it still build fail ,please click security tab ， and click Advaced(V)
make sure your account access has Complete control ,default all allow is TrustedInstaller user ,this will prevented by Mcafee ;

wish it helped all who met this err ,I had troubled by it for months ;

@herohenu I build GO on window 10 with McAfee, unfortunately I no admin right to change any settings.

Anyway, thx for your remind.

Also hit this issue:

Windows 10 1903/18362.1016 with debian under WSL 1.
go version go1.15 linux/amd64
Running McAfee AV. There's both the on-demand scanning and currently a schedule scan running
I had gone so far as to rm -rf ~/go/* but that didn't help
Worked around with: GODEBUG=modcacheunzipinplace=1 go mod tidy

For fellow McAfee sufferers, this vague page may be related: https://kc.mcafee.com/corporate/index?page=content&id=KB91411

Change https://golang.org/cl/258798 mentions this issue: cmd/go/internal/modfetch: always extract module directories in place

Is the fix from https://golang.org/cl/258798 part of release go1.16beta1 ?

@egodigitus

@egodigitus, yes, that change is included in go1.16beta1.

go1.16beta1 fixed the bug for me 👍
OS: Windows 10
Running golang inside WSL Ubuntu 20.04

cmd/go/internal/modfetch: always extract module directories in place

Navigation Menu

cmd/go: 'Access is denied' when renaming module cache directory #36568

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

86 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	// Check whether the directory was populated while we were waiting on the lock.
	fi, err = os.Stat(dir)

cmd/go: 'Access is denied' when renaming module cache directory #36568

Description

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

Activity

cagedmantis commented on Jan 16, 2020

jayconrod commented on Jan 16, 2020

kiwionly commented on Jan 17, 2020

bcmills commented on Jan 22, 2020

86 remaining items

herohenu commented on Jun 30, 2020

kiwionly commented on Jul 1, 2020

SelfDrivingCarp commented on Aug 26, 2020

gopherbot commented on Oct 1, 2020

egodigitus commented on Jan 27, 2021

bcmills commented on Jan 27, 2021

egodigitus commented on Jan 27, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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

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