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

os: Readlink should return destination even if link is broken #31996

Closed
mfojtik opened this issue May 13, 2019 · 6 comments
Closed

os: Readlink should return destination even if link is broken #31996

mfojtik opened this issue May 13, 2019 · 6 comments

Comments

@mfojtik
Copy link

@mfojtik mfojtik commented May 13, 2019

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

$ go version
go version go1.12.5 darwin/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
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPROXY=""
GORACE=""
GOTMPDIR=""
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

When reading a symlink with non-existing target the os.Readlink will return empty string and error. That makes reading the path of the target impossible.

For example, if you are in container and use shared PID namespace (which means you share the /proc) and you want to get a PID, one way to do so is to follow the /proc/PID/exe link.
In case of shared PID namespace, if you don't use the same image for containers sharing the /proc, it will return broken link (which is OK). Unfortunately, os.Readlink can't be used to get the destination string.

What did you expect to see?

I want to see the destination of a symlink, even when os.Readlink is not able to follow the link. It is fine to return the error, but the destination can be returned as well.
The caller can decide to ignore (or not to ignore) the returned destination.
There should be no breakage to existing code.

What did you see instead?

The os.Readlink return "", error on broken link.

@andybons andybons changed the title os: Readlink does not return destination when link is broken os: Readlink should return destination even if link is broken May 13, 2019
@andybons

This comment has been minimized.

Copy link
Member

@andybons andybons commented May 13, 2019

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 13, 2019

I'm sorry, I don't understand what you mean. This program shows an example of reading a symlink whose destination does not exist, and it works without error.

package main

import (
	"fmt"
	"io/ioutil"
	"os"
	"path/filepath"
)

func main() {
	tmpdir, err := ioutil.TempDir("", "readlink")
	if err != nil {
		panic(err)
	}
	defer os.RemoveAll(tmpdir)
	from := filepath.Join(tmpdir, "from")
	to := filepath.Join(tmpdir, "to")
	if err := os.Symlink(to, from); err != nil {
		panic(err)
	}
	fmt.Println(os.Readlink(from))
}
@networkimprov

This comment has been minimized.

Copy link

@networkimprov networkimprov commented May 14, 2019

/proc/PID/exe is not a normal symlink; it's a resource of procfs.

This might reproduce it:

$ ln /usr/bin/cat ./mycat
$ ./mycat &
$ mypid=$!
$ rm ./mycat
$ ls -l /proc/$mypid/exe // try Go app with os.Readlink() here
$ kill %1
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 14, 2019

Thanks for the example. But when I try that on my system, os.Readlink("/proc/3540/exe") returns without error.

@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented May 14, 2019

@mfojtik, you say you're using go version go1.12.5 darwin/amd64 but there's no /proc on macOS.

What is your environment?

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jun 13, 2019

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@gopherbot gopherbot closed this Jun 13, 2019
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
6 participants
You can’t perform that action at this time.