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: mod vendor does not preserve execute permission for scripts #34965

Closed
aanm opened this issue Oct 17, 2019 · 4 comments
Closed

cmd/go: mod vendor does not preserve execute permission for scripts #34965

aanm opened this issue Oct 17, 2019 · 4 comments

Comments

@aanm
Copy link

@aanm aanm commented Oct 17, 2019

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

$ go version
1.13.1

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
GOHOSTARCH="amd64"
GOHOSTOS="linux"

What did you do?

main.go

package main

func main() {
        fmt.Println("hello go")
}

tools.go

// +build tools

package main

import (
        _ "k8s.io/code-generator"
)

go.mod

module aanm/go-test/test

go 1.13

require k8s.io/code-generator v0.0.0-00010101000000-000000000000

replace (
        k8s.io/code-generator => k8s.io/kubernetes/staging/src/k8s.io/code-generator v0.0.0-20191012044237-c97fe5036ef3
        k8s.io/kubernetes => k8s.io/kubernetes v1.16.2
)

run

$ go mod tidy
$ go mod vendor

What did you expect to see?

the file permissions of generate-groups.sh to be kept the same as the original file.

$ # original repo in the same tag v1.16.2
$ ls -la k8s.io/kubernetesstaging/src/k8s.io/code-generator/generate-groups.sh 
-rwx------. 1 aanm aanm 3837 Apr 25 12:25 staging/src/k8s.io/code-generator/generate-groups.sh

What did you see instead?

$ ls -la vendor/k8s.io/code-generator/generate-groups.sh 
-rw-------. 1 aanm aanm 3837 Oct 17 21:59 vendor/k8s.io/code-generator/generate-groups.sh
@agnivade agnivade changed the title go mod vendor does not keep original vendor file permissions cmd/go: mod vendor does not keep original vendor file permissions Oct 18, 2019
@agnivade

This comment has been minimized.

Copy link
Contributor

@agnivade agnivade commented Oct 18, 2019

@bcmills bcmills added the modules label Oct 18, 2019
@bcmills bcmills added this to the Backlog milestone Oct 18, 2019
@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Oct 18, 2019

This issue is probably the same root cause as reported in #31481 (comment), but (per #31481 (comment)) let's keep this issue open to track that particular detail.

@bcmills bcmills changed the title cmd/go: mod vendor does not keep original vendor file permissions cmd/go: mod vendor does not preserve execute permission for scripts Oct 21, 2019
@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Oct 24, 2019

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 still believe this is the right decision. We can go arbitrarily far in "preserving" file metadata, and the result would still miss some kinds of metadata and fail to recreate other metadata on some subset of systems (symlinks, odd file modification times, etc).

Tests that need special files (anything beyond files containing bytes) can write them to a temporary directory and configure them as they wish.

Install scripts can be invoked as bash ./script (or cat script | bash) instead of ./script.

I don't believe this decision was wrong. But even if it were, it is a fundamental design decision made years ago that would be very hard to change now - it would invalidate all the checksums (if this extra information is important enough to preserve it would have to be checksummed too). It would have to be very wrong to be worth the pain of correcting.

@jayconrod

This comment has been minimized.

Copy link
Contributor

@jayconrod jayconrod commented Oct 24, 2019

Closing this as working as intended. Thanks for clarifying!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.