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: follow root dir symlink in fsys.Walk (though not other symlinks in the tree) #50807
Comments
I filed #50804 for the equivalent behavior in |
This issue is currently labeled as early-in-cycle for Go 1.19. |
When is this going to be fixed? filepath.Walk does not allow for traversing links |
@sternopanko Go is an open source project, so if this is a problem then perhaps you could send a patch to fix it yourself. Note that this issue is only about a symlink at the root of the tree, so we don't need a new filepath function to handle it, just an extra step before the call to |
@sternopanko, this issue is about a specific workaround in I filed #50804 for a more general It is certainly possible to implement a |
That facebook solution is a nice one |
@ianlancetaylor the solution is slightly less intuitive than you might think but is very easy to implement |
Of course to detect a loop in the tree (at least for linux) |
Change https://go.dev/cl/448360 mentions this issue: |
Change https://go.dev/cl/461959 mentions this issue: |
Reopened because I reverted the attempted fix as https://go.dev/cl/461959. |
This reverts CL 448360 and adds a regression test for #57754. Reason for revert: broke 'go list' in Debian's distribution of the Go toolchain Fixes #57754. Updates #50807. Change-Id: I3e8b9126294c55f21572774b549fb28f29eded0f Reviewed-on: https://go-review.googlesource.com/c/go/+/461959 Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com>
Change https://go.dev/cl/463179 mentions this issue: |
Change https://go.dev/cl/463177 mentions this issue: |
Change https://go.dev/cl/463176 mentions this issue: |
This also makes path/filepath.Walk more consistent between Windows and POSIX platforms. According to https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/basedefs/V1_chap04.html#tag_04_12 symlinks in a path that includes a trailing slash must be resolved before a function acts on that path. POSIX defines an lstat function, whereas the Win32 API does not, so Go's os.Lstat should follow the (defined) POSIX semantics instead of doing something arbitrarily different. CL 134195 added a test for the correct POSIX behavior when os.Lstat is called on a symlink. However, the test turned out to be broken on Windows, and when it was fixed (in CL 143578) it was fixed with different Lstat behavior on Windows than on all other platforms that support symlinks. In #50807 we are attempting to provide consistent symlink behavior for cmd/go. This unnecessary platform difference, if left uncorrected, will make that fix much more difficult. CL 460595 reworked the implementation of Stat and Lstat on Windows, and with the new implementation this fix is straightforward. For #50807. Updates #27225. Change-Id: Ia28821aa4aab6cefa021da2d9b803506cdb2621b Reviewed-on: https://go-review.googlesource.com/c/go/+/463177 Reviewed-by: Quim Muntal <quimmuntal@gmail.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com>
For #51506. For #50807. Change-Id: I4c0ae85a2103ac4f07351a4f01ce24fa02f03104 Reviewed-on: https://go-review.googlesource.com/c/go/+/463176 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Russ Cox <rsc@golang.org>
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>
cmd/go currently doesn't follow symlinks when looking for packages when module roots (or the current directory in the case of ...). Though we don't want to follow symlinks within modules, it is often confusing to users when their current working directory is a symlink. When walking a directory tree, use stat rather than lstat when reading the root directory to follow the symlink. This will allow users to use the go command as they'd expect when the working directory is a symlink following symlinks within modules.
@bcmills
The text was updated successfully, but these errors were encountered: