cmd/go: work use failing with symlinks in the path #68383
Assignees
Labels
GoCommand
cmd/go
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Comments
cagedmantis
changed the title
seankhliao
added
NeedsInvestigation
|
Change https://go.dev/cl/603136 mentions this issue: |
|
Change https://go.dev/cl/630276 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Nov 20, 2024
This CL first removes the base.ShortPathConservative function. It had two classes of uses. The first was in opening files where the paths end up in error messages. In all those cases, the non-shortened paths are used to open the files, and ShortPath is only used for the error messages. The second is in base.RelPaths. RelPaths will now call ShortPath for each of the paths passed in instead of calling RelConservative and then doing the same check as ShortPath to see if the path is shorter. To avoid the possibility of incorrect relative paths ending up in error messages (that might have command lines suggested for users to run), and to avoid the possibility of incorrect relative paths appearing in the output of base.RelPaths, base.ShortPaths always does an os.SameFile check to make sure that the relative path its providing is actually correct. Since this makes ShortPath slower than just manipulating paths (because we need to stat the files), we need to be continue to enforce that ShortPath is only called for error messages (with the exception of base.RelPaths and its callers). This is a simpler way of solving the problem that base.ShortPaths intended to solve. For #68383 Change-Id: I474f464f51a9acb2250069dea3054b55d95a4ab4 Reviewed-on: https://go-review.googlesource.com/c/go/+/630276 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Sam Thanawalla <[email protected]>
|
Change https://go.dev/cl/630280 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Nov 21, 2024
This CL rolls forward CL 630276, fixing the issues with the longtest builders that required the revert in CL 630317. The change this CL makes compared to CL 630276 is adding the shortPathErrorList function to rewrite the paths in the modfile.Errors in a modfile.ErrorList using base.ShortPath and calling it on the error returned from modfile.Parse. The following is the commit message from the original change: This CL first removes the base.ShortPathConservative function. It had two classes of uses. The first was in opening files where the paths end up in error messages. In all those cases, the non-shortened paths are used to open the files, and ShortPath is only used for the error messages. The second is in base.RelPaths. RelPaths will now call ShortPath for each of the paths passed in instead of calling RelConservative and then doing the same check as ShortPath to see if the path is shorter. To avoid the possibility of incorrect relative paths ending up in error messages (that might have command lines suggested for users to run), and to avoid the possibility of incorrect relative paths appearing in the output of base.RelPaths, base.ShortPaths always does an os.SameFile check to make sure that the relative path its providing is actually correct. Since this makes ShortPath slower than just manipulating paths (because we need to stat the files), we need to be continue to enforce that ShortPath is only called for error messages (with the exception of base.RelPaths and its callers). This is a simpler way of solving the problem that base.ShortPaths intended to solve. For #68383 Change-Id: Ibcefb343535bd82999916b2282e9b512bb683433 Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-linux-amd64-longtest Reviewed-on: https://go-review.googlesource.com/c/go/+/630280 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Sam Thanawalla <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Go version
go version go1.22.0 linux/amd64
Output of
go envin your module/workspace:What did you do?
I was reviewing the suggestions for local patching in this article
https://eli.thegreenplace.net/2024/locally-patching-dependencies-in-go/
Go workspaceswas one of the suggestions. I tried the code in path on the local file system accessed through a symlink namedProjectsand tried to invokego work usecommand.It looks like
go workskips one level if a symlink is usedIf I don't use the symlink to access the working directory everything works fine
What did you see happen?
go mod usefails if I use the symlink to access the working directory.What did you expect to see?
go mod useto create go.work file and correctly refer the directories with go.mod filesThe text was updated successfully, but these errors were encountered: