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 list can't follow symlink #57754

Closed
zhsj opened this issue Jan 12, 2023 · 7 comments
Closed

cmd/go: go list can't follow symlink #57754

zhsj opened this issue Jan 12, 2023 · 7 comments
Assignees
@bcmills
Labels
FrozenDueToAge GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.20

Comments

@zhsj
Copy link
Contributor

zhsj commented Jan 12, 2023

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

$ go version
go version go1.20rc2 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="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/zsj/.cache/go-build"
GOENV="/home/zsj/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/zsj/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/zsj/go"
GOPRIVATE=""
GOPROXY="https://goproxy.cn"
GOROOT="/usr/lib/go-1.20"
GOSUMDB="sum.golang.google.cn"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.20/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20rc2"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/zsj/Workspaces/debian/package/pkg-go/golang-go.uber-atomic/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build166984776=/tmp/go-build -gno-record-gcc-switches"

What did you do?

zsj@debian:~/golang-go.uber-atomic$ go list go.uber.org/atomic/...
pattern go.uber.org/atomic/...: lstat ../../share/go-1.20/src: no such file or directory

What did you expect to see?

Like go1.19

zsj@debian:~/golang-go.uber-atomic$ /usr/lib/go-1.19/bin/go list go.uber.org/atomic/...
go.uber.org/atomic
go.uber.org/atomic/internal/gen-atomicint
go.uber.org/atomic/internal/gen-atomicwrapper

What did you see instead?

lstat ../../share/go-1.20/src: no such file or directory

The golang package in Debian installs the src at /usr/share/go-1.20/src/, but the go command is at /usr/lib/go-1.20/bin/. The it creates a symlink like

$ l /usr/lib/go-1.20/src
lrwxrwxrwx 1 root root 23 Jan  5 16:01 /usr/lib/go-1.20/src -> ../../share/go-1.20/src/

I'm not sure why we do that, but it has been such layout for a long time. Maybe to conform FHS policy.

A quick debug with strace shows:

[pid 521295] newfstatat(AT_FDCWD, "/usr/lib/go-1.20/src", {st_mode=S_IFLNK|0777, st_size=23, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid 521295] readlinkat(AT_FDCWD, "/usr/lib/go-1.20/src", "../../share/go-1.20/src", 128) = 23
[pid 521295] newfstatat(AT_FDCWD, "../../share/go-1.20/src", 0xc000498ed8, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
pattern go.uber.org/atomic/...: lstat ../../share/go-1.20/src: no such file or directory

Seems it doesn't follow the symlink with right base?
@bcmills
Copy link
Contributor

bcmills commented Jan 12, 2023

Is this a regression in Go 1.20? (If so, CL 448360 could plausibly be related.)

@bcmills bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Jan 12, 2023
@bcmills bcmills added this to the Go1.20 milestone Jan 12, 2023
@bcmills bcmills self-assigned this Jan 12, 2023
@zhsj
Copy link
Contributor Author

zhsj commented Jan 12, 2023

Is this a regression in Go 1.20?

Yes.

(If so, CL 448360 could plausibly be related.)

Thanks. after I reverted CL 448360, it works.

@bcmills
Copy link
Contributor

bcmills commented Jan 12, 2023

I am able to reproduce this in a test script. I think we're not handling relative paths from os.Readlink properly here:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/fsys/fsys.go;l=518;drc=ea4631cc0cf301c824bd665a7980c13289ab5c9d

@bcmills bcmills mentioned this issue Jan 12, 2023
Closed
@bcmills
Copy link
Contributor

bcmills commented Jan 12, 2023

Just to set expectations: I don't know if this will make Go 1.20, but if not I expect it should be fixed by Go 1.20.1.

@gopherbot
Copy link

Change https://go.dev/cl/461681 mentions this issue: fsys: resolve root symlink using filepath.EvalSymlinks instead of os.Readlink

@gopherbot
Copy link

Change https://go.dev/cl/461959 mentions this issue: Revert "internal/fsys: follow root symlink in fsys.Walk"

@bcmills bcmills mentioned this issue Jan 13, 2023
Closed
@gopherbot
Copy link

Change https://go.dev/cl/463179 mentions this issue: cmd/go: traverse module-root symlinks in Walk calls

gopherbot pushed a commit that referenced this issue Jan 31, 2023
@gopherbot
cmd/go: traverse module-root symlinks in Walk calls
f36c7c5 
fsys.Walk, like filepath.Walk, avoids traversing symlinks. Also like
filepath.Walk, it follows a symlink at the root if the root path ends
in a file separator (consistent with POSIX pathname resolution¹).

If the user's working directory is within a repository stored in
(and symlinked to) a different filesystem path, we want to follow the
symlink instead of treating the module as completely empty.

¹https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/basedefs/V1_chap04.html#tag_04_12

Fixes #50807.
Updates #57754.

Change-Id: Idaf6168dfffafe879e05b4ded5fda287fcd3eeec
Reviewed-on: https://go-review.googlesource.com/c/go/+/463179
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
johanbrandhorst pushed a commit to Pryz/go that referenced this issue Feb 12, 2023
@johanbrandhorst
cmd/go: traverse module-root symlinks in Walk calls
e311275 
fsys.Walk, like filepath.Walk, avoids traversing symlinks. Also like
filepath.Walk, it follows a symlink at the root if the root path ends
in a file separator (consistent with POSIX pathname resolution¹).

If the user's working directory is within a repository stored in
(and symlinked to) a different filesystem path, we want to follow the
symlink instead of treating the module as completely empty.

¹https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/basedefs/V1_chap04.html#tag_04_12

Fixes golang#50807.
Updates golang#57754.

Change-Id: Idaf6168dfffafe879e05b4ded5fda287fcd3eeec
Reviewed-on: https://go-review.googlesource.com/c/go/+/463179
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
@golang golang locked and limited conversation to collaborators Jan 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@bcmills bcmills

Labels
FrozenDueToAge GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.20
Development

No branches or pull requests
3 participants
@zhsj @bcmills @gopherbot