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

cmd/go: 'Access is denied' when renaming module cache directory [1.14 backport] #37800

Open
gopherbot opened this issue Mar 11, 2020 · 6 comments
Open

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 11, 2020

@jayconrod requested issue #36568 to be considered for backport to the next 1.14 minor release.

@gopherbot Please open backport issue for 1.14.

@jayconrod

This comment has been minimized.

Copy link
Contributor

@jayconrod jayconrod commented Mar 11, 2020

CL 221820 mitigates #36568, an issue where antivirus (or a similar program) prevents modules from being extracted into the module cache. That CL makes two changes:

  1. os.Rename (the operation that fails) is re-attempted multiple times over 2000 ms. This should make the error less frequent, but doesn't eliminate it entirely.
  2. Adds compatibility with a future change, added in CL 221157 but disabled by default, where modules are extracted in place without requiring os.Rename.

CL 221157 is the proper solution for this problem, but it can't be enabled yet because older versions of the Go command (1.14 and earlier) assume that if a module directory is present, it is fully extracted and ready to use. So if Go 1.14 and 1.15 access the same module directory concurrently, 1.14 might see a partially extracted module. CL 221820 prevents that from happening.

The flag in CL 221157 can be flipped safely when 1.14 and older versions are no longer supported and no longer in use. That would probably be true for 1.17.

I'd like to speed up the migration by backporting CL 221820 to 1.14, probably 1.14.2. That would allow us to flip the flag in 1.16.

@networkimprov

This comment has been minimized.

Copy link

@networkimprov networkimprov commented Mar 11, 2020

Older releases remain in use well after they're no longer supported, so we should also backport to 1.13. It's possible that many sites will skip 1.14 entirely due to its major runtime changes and bumpy launch.

@jayconrod

This comment has been minimized.

Copy link
Contributor

@jayconrod jayconrod commented Mar 11, 2020

I've just opened #37802 for 1.13 backport.

@gopherbot

This comment has been minimized.

Copy link
Author

@gopherbot gopherbot commented Mar 12, 2020

Change https://golang.org/cl/223146 mentions this issue: [release-branch.go1.13] cmd/go: make module zip extraction more robust

@gopherbot

This comment has been minimized.

Copy link
Author

@gopherbot gopherbot commented Mar 12, 2020

Change https://golang.org/cl/223147 mentions this issue: [release-branch.go1.14] cmd/go: make module zip extraction more robust

@cagedmantis cagedmantis modified the milestones: Go1.14.1, Go1.14.2 Mar 19, 2020
@cagedmantis

This comment has been minimized.

Copy link
Contributor

@cagedmantis cagedmantis commented Mar 20, 2020

Approved. This is a serious issue without a reasonable workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.