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

x/tools/cmd/fiximports: don't use .biz extension in testdata #38329

Open
BertHooyman opened this issue Apr 9, 2020 · 9 comments
Open

x/tools/cmd/fiximports: don't use .biz extension in testdata #38329

BertHooyman opened this issue Apr 9, 2020 · 9 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
Unplanned

Comments

@BertHooyman
Copy link

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

go version go1.14.2 windows/amd64

Does this issue reproduce with the latest release?

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

go env Output
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\bert.hooyman\AppData\Local\go-build
set GOENV=C:\Users\bert.hooyman\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\bert.hooyman\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,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=NUL
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\BERT~1.HOO\AppData\Local\Temp\go-build874685950=/tmp/go-build -gno-record-gcc-switches

What did you do?

go get -v golang.org/x/tools/gopls

What did you expect to see?

successful tool install

What did you see instead?

go: downloading golang.org/x/tools v0.0.0-20200408132156-9ee5ef7a2c0d
-> unzip C:\Users\bert.hooyman\go\pkg\mod\cache\download\golang.org\x\tools@v\v0.0.0-20200408132156-9ee5ef7a2c0d.zip: mkdir C:\Users\bert.hooyman\go\pkg\mod\golang.org\x\tools@v0.0.0-20200408132156-9ee5ef7a2c0d.tmp-041877873\cmd\fiximports\testdata\src\titanic.biz: Access is denied.
go: golang.org/x/tools/gopls upgrade => v0.3.4
-> unzip C:\Users\bert.hooyman\go\pkg\mod\cache\download\golang.org\x\tools@v\v0.0.0-20200316194252-fafb6e2e8a4a.zip: mkdir C:\Users\bert.hooyman\go\pkg\mod\golang.org\x\tools@v0.0.0-20200316194252-fafb6e2e8a4a.tmp-669779996\cmd\fiximports\testdata\src\titanic.biz: Access is denied.
go get golang.org/x/tools/gopls: unzip C:\Users\bert.hooyman\go\pkg\mod\cache\download\golang.org\x\tools@v\v0.0.0-20200316194252-fafb6e2e8a4a.zip: mkdir C:\Users\bert.hooyman\go\pkg\mod\golang.org\x\tools@v0.0.0-20200316194252-fafb6e2e8a4a.tmp-669779996\cmd\fiximports\testdata\src\titanic.biz: Access is denied.

The problem I am seeing is essentially: mkdir titanic.biz
.biz is a ransomware extension Symantec will block it.
My system has Symantec Enpoint Protection, and my employer won't let me switch it off.
.biz is a bad choice for a testdata folder name suffix.
@gopherbot gopherbot added this to the Unreleased milestone Apr 9, 2020
@gopherbot gopherbot added the Tools This label describes issues relating to any tools in the x/tools repository. label Apr 9, 2020
@qmuntal
Copy link
Contributor

qmuntal commented Apr 9, 2020

Probably the same issue described in #36568 and partially fixed in 1.14.2.

@BertHooyman
Copy link
Author

BertHooyman commented Apr 9, 2020 •
edited

Update: I was able to convince SysAdmin to suspend my Symantec Endpoint Protection for an hour. I could do "Go: Install/Update Tools" in VS Code and get all tools installed flawlessly at the first try.

The single problem was the .biz foldername extension. I thought it useful for the community to understand this 'edge' problem.

@stamblerre stamblerre changed the title x/tools/cmd/fiximports x/tools/cmd/fiximports: don't use .biz extension in testdata Apr 10, 2020
@stamblerre
Copy link
Contributor

/cc @heschik

@andybons andybons added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 10, 2020
@heschi
Copy link
Contributor

heschi commented Apr 20, 2020

@bcmills @jayconrod is this a dupe of #36568? This is an error on directory creation rather than rename.

@jayconrod
Copy link
Contributor

No, it doesn't look like a duplicate of #36568. In the error log here's it's failing while extracting the x/tools module zip, not when renaming the directory.

@BertHooyman So it sounds like your organization has a policy against creating files that end with .biz? I'm not sure how we can anticipate that kind of thing.

@heschi
Copy link
Contributor

heschi commented Apr 20, 2020

These files are years old and we've never had a problem before AFAIK. I can review a change to rename them but I don't think I'm going to do it myself.

@BertHooyman
Copy link
Author

@jayconrod I'm not sure whether my company has 'special' rules or these rules come with Symantec Endpoint Protection. It's an edge condition for sure. Either way, having the scenario mentioned here might be sufficient for others experiencing the exact same error message "Access is denied" on a mkdir. It took me quite a while to weed through all the seemingly related mentions (not just in x/tools), so having it here might help people. I understand if the issue is not 'resolved'.

@bcmills
Copy link
Contributor

bcmills commented Apr 21, 2020

It doesn't seem plausible for us to work around every IT department's arbitrary restrictions on filenames.

I agree with @heschik: we can review a change to work around this restriction, but we shouldn't do it proactively. I would add to that that the commit message should include a reference to some specific documentation about why (and, ideally, under what conditions) those names are disallowed.

@bcmills bcmills modified the milestones: Unreleased, Unplanned Apr 21, 2020
@BertHooyman
Copy link
Author

@bcmills thats perfectly understandable. I would suggest to make the root cause discoverable by those who suffer from it. So that users understand that when a mkdir leads to an Access Denied (on Windows), they understand it's not Go Tools' fault, but their endpoint protection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
8 participants
@jayconrod @andybons @qmuntal @bcmills @stamblerre @gopherbot @BertHooyman @heschi