-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: Stat does not follow relative symlinks on windows #19870
Comments
Oh my! I suspect almost all
IIUC, relative symlinks are not relative to $CWD, but relative to link path. EDITED: |
Correct. |
Double correct. :-) @hirochachacha would you like to send a change? With new test ... Alex PS: simplified version of the test above https://play.golang.org/p/vrY_AAb47I |
Yeah! it must be correct.
Sure! I'll do few hours later. |
CL https://golang.org/cl/39932 mentions this issue. |
On Windows, calling os.Stat() on a symlinked file can return a file not found error instead of following the link. This change normalizes the path by calling EvalSymlinks on it first. See golang/go#19870 (comment). Furthermore, I've cleaned up the code significantly here to be more streamlined and clear. Fixes cockroachdb#14546.
On Windows, os.Stat() interprets evaluates symlinks relative to the current working directory rather than the symlink's directory. This change normalizes the path by calling EvalSymlinks on it first. See golang/go#19870 (comment). Furthermore, I've cleaned up the code significantly here to be more streamlined and clear. Fixes cockroachdb#14546.
@alexbrainman I think path/filepath.EvalSymlinks covers relative symlinks well. https://github.com/golang/go/blob/master/src/path/filepath/path_test.go#L752-L834 IMO, there are no need to add extra tests. Sorry about misdirection. |
On Windows, os.Stat() interprets evaluates symlinks relative to the current working directory rather than the symlink's directory. This change normalizes the path by calling EvalSymlinks on it first. See golang/go#19870 (comment). Furthermore, I've cleaned up the code significantly here to be more streamlined and clear. Fixes cockroachdb#14546.
On Windows, os.Stat() interprets evaluates symlinks relative to the current working directory rather than the symlink's directory. This change normalizes the path by calling EvalSymlinks on it first. See golang/go#19870 (comment). Furthermore, I've cleaned up the code significantly here to be more streamlined and clear. Fixes cockroachdb#14546.
On Windows, os.Stat() interprets evaluates symlinks relative to the current working directory rather than the symlink's directory. This change normalizes the path by calling EvalSymlinks on it first. See golang/go#19870 (comment). Furthermore, I've cleaned up the code significantly here to be more streamlined and clear. Fixes cockroachdb#14546.
On Windows, os.Stat() interprets evaluates symlinks relative to the current working directory rather than the symlink's directory. This change normalizes the path by calling EvalSymlinks on it first. See golang/go#19870 (comment). Furthermore, I've cleaned up the code significantly here to be more streamlined and clear. Fixes cockroachdb#14546.
Sounds good. Thank you for looking. Alex |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.8 windows/amd64
What operating system and processor architecture are you using (
go env
)?What did you do?
I ran a modified version of
os.TestSymLink
which creates relative symlinks outside of the cwd:What did you expect to see?
The same result I see on darwin:
What did you see instead?
The text was updated successfully, but these errors were encountered: