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: go mod vendor looses executable bit in vendored files #45231

Closed
thaJeztah opened this issue Mar 25, 2021 · 3 comments
Closed

cmd/go: go mod vendor looses executable bit in vendored files #45231

thaJeztah opened this issue Mar 25, 2021 · 3 comments
Labels
FrozenDueToAge

Comments

@thaJeztah
Copy link
Contributor

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

$ go version
go version go1.16.2 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.2"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/go/repro/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-build1216370537=/tmp/go-build -gno-record-gcc-switches"

What did you do?

While migrating a project from GoDeps to go modules, I noticed that some vendored files changed their permissions from 0755 to 0655. Looking for the source of truth, I looked at the files in the upstream repository, which showed that 0755 was the correct permission.

To reproduce:

mkdir repro && cd repro

cat > foo.go <<'EOF'
package repro

import "golang.org/x/sys/unix"

_ = unix.R_OK
EOF

go mod init repro && go mod tidy
# go: finding golang.org/x/sys/unix latest
# go: finding golang.org/x/sys latest
# go: downloading golang.org/x/sys v0.0.0-20210324051608-47abb6519492

go mod vendor
ls -la vendor/golang.org/x/sys/unix/mkall.sh
# -rw-r--r--    1 root     root          8528 Mar 25 12:07 vendor/golang.org/x/sys/unix/mkall.sh

Verifying the file permissions in the upstream source repository;

git clone https://github.com/golang/sys.git golang-sys
ls -la golang-sys/unix/mkall.sh
# -rwxr-xr-x    1 root     root          8528 Mar 25 12:09 golang-sys/unix/mkall.sh

What did you expect to see?

In this case, these files (shell and perl scripts) may not be needed in the vendor directory, but since they are included, file mode should be preserved.

What did you see instead?

Files having the incorrect mode.
@ALTree
Copy link
Member

ALTree commented Mar 25, 2021

I believe this is a dup of #34965, which was closed as Working As Intended; see in particular #34965 (comment) by Russ.

@thaJeztah
Copy link
Contributor Author

Ah, thanks! I tried searching, but only found the ones about permissions in the go module cache.

We defined the Go module representation to be absolutely least common denominator across systems for portability. The Go module zip file is for dependencies that need to be downloaded and built by the go command. It is not meant to support anything more. By design, there are no permission bits, nor special files like symlinks, nor modification times.

I'm not sure if I agree with the choice here; IMO files should either be included (verbatim copy), or not included. Including files but discarding information that may have been set on purpose feels tricky.

That said; for the example at hand here (some script files), I could see that excluding those files could make sense.

@bcmills
Copy link
Contributor

bcmills commented Mar 25, 2021

Duplicate of #34965

@bcmills bcmills marked this as a duplicate of #34965 Mar 25, 2021
@bcmills bcmills closed this as completed Mar 25, 2021
@golang golang locked and limited conversation to collaborators Mar 25, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@thaJeztah @ALTree @bcmills @gopherbot