-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
cmd/go: 'Access is denied' when renaming module cache directory #36568
Comments
@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 |
@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 )
|
For the go/src/cmd/go/internal/modfetch/fetch.go Line 76 in 6718cb6
go/src/cmd/go/internal/modfetch/fetch.go Lines 82 to 83 in 6718cb6
go/src/cmd/go/internal/modfetch/fetch.go Line 122 in 6718cb6
So the only possibilities I can see for this failure are:
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 CC @jstarks @alexbrainman @zx2c4 @networkimprov in case they have any insights into how to debug this. |
@bcmills is this the relevant WinAPI call for lockedfile.Mutex? How is it used here? Since the error is intermittent, it seems like retrying os.Rename() might be the solution. Unrelated directory updates could have saturated the NTFS journal (@jstarks is that a reasonable guess?) A way to test that might be a set of goroutines, each repeatedly renaming a separate file between two unique names in the same directory; there's no possibility of name collisions, only concurrent directory updates. PS: If that's the problem, I don't think it's a bug in NTFS per se... |
Yes, |
What would it mean to saturate the NTFS journal? If the program is outpacing the buffering capacity of the filesystem, I would expect |
My guess about NTFS may be wrong. It's the only reason I could imagine for unexplained rename failures. My test concept above might prove it... |
Some info on NTFS journaling is here, tho not linked to a particular Windows version. It describes "Log Full", but isn't clear about the end result for filesystem ops which encounter it. Some are retried, but not all? I can't tell. |
I don't have any good ideas. I am not familiar with that code. And I don't have free time to learn the code to debug it. Alex |
@bcmills here's a test app which repeatedly renames a set of files in a single directory. It defaults to 10 concurrent renaming loops, and a command line argument lets you pick the quantity. I tried this using Go 1.13.3 on Win7 with 10, 33, 100, and 250 loops, but saw no errors. Maybe it behaves differently on Win10, or a higher loop count is required? Maybe it should also write files, not just change directory entries? Or maybe it disproves my hypothesis :-) I watched the Task Manager while it ran, and noticed that SearchIndexer.exe also consumes a lot of cpu time.
|
I see this error many times in my Windows 10 workstation when downloading dependencies that are not cached locally, and it also happen to all my colleagues. In our case it seems to be related to the on-access scanner enterprise antivirus detecting as a threat the go modules cache renames. It is happening since the adoption of modules on Go 1.11. The only solution I've found is to create an scanning exception for the |
I don’t know if this can be useful. I posted on vscode-go a way to reproduce the issue. |
@alfmos, do you have repro steps that do not involve indirection through VSCode? Ideally we should have a regression test that we can check in to the main |
@bcmills I've just tried from cmd and I get the error. go version: 1.13.7 windows/amd64 Steps to reproduce the issue: Tell me what data you need and I'll collect them. |
I spent some more timing looking at this today. Based on the Here's our normal sequence of operations at a high level:
We're getting I thought about an alternate flow where we extract a module version to its final location, then create a special file indicating everything has been extracted. However, if we encounter an error extracting the module, we would need to call I don't think we can fix this, but some mitigations are possible. First, we can check if the error is Second, we can retry |
I did try that before posting. No effect. Also the output above is in a fresh go folder as shown. |
@S1erraQ Thanks, that confirms this is the same issue. I missed something though: Go 1.14.2 is compatible with the new behavior triggered by If you're comfortable living on the bleeding edge, gotip can build a Go toolchain from the |
Really? I specifically searched for the commit and traced it to release 1.14.2 and could confirm a change in behavior ONLY after setting the env. Seemed like a big coincident... |
@jayconrod thanks for the explanation. I guess then the 2s interval is what truly helped me... |
Change https://golang.org/cl/230537 mentions this issue: |
For #36568 For #34527 Change-Id: Ieea4b4a7644e9c957f48d08d2e172e39b571502f Reviewed-on: https://go-review.googlesource.com/c/go/+/230537 Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
For golang#36568 For golang#34527 Change-Id: Ieea4b4a7644e9c957f48d08d2e172e39b571502f Reviewed-on: https://go-review.googlesource.com/c/go/+/230537 Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
@kiwionly do u use Ubuntu 18.04 on windows 10 ? if it still build fail ,please click security tab , and click Advaced(V) 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:
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: |
Is the fix from https://golang.org/cl/258798 part of release go1.16beta1 ? |
@egodigitus, yes, that change is included in |
|
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
OutputWhat 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.
The text was updated successfully, but these errors were encountered: