-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/go: malformed file path: invalid char ':' #28001
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
Comments
Sounds like (away from keyboard) a dup of #26672 |
You're right. But perhaps the workaround there isn't satisfactory here - let's see what @vitarb has to say. |
Modules are intended to be portable across platforms, and the |
He's saying that it's non-Go files in the repo that are causing it, though, not the module path itself, or even files that the toolchain is going to care about directly. It looks like Git for Windows just ignores the files, which means that they'll wind up deleted if you commit and you're not paying attention. Since these are apparently files that aren't an issue in terms of importing the repository and the module is presumably being cloned into the cache where commits are fairly unlikely to happen, maybe the tools could complain only if it's a Go, C, or assembly file that's illegal? |
If they are non-Go files needed for testing some Go package, then If they are non-Go files that are also not needed for testing any Go package, why can't they be pruned out of the Go module in the first place (e.g. by adding another |
You must be thinking in terms of centralized codebase where such things can be
done easier.
I don't think we can guarantee on the go toolchain level that tests would succeed on all platforms or that package would even build, if package is not supporting some platforms due to whatever reasons be that file naming, build constraints or platform dependent code, it should be totally fine. For example if I want to write a package that only works on Linux and you find it useful, you should be able to consume it if you are going to use it only on Linux.
On the other hand I'm not going to justify usefulness of those filenames and if you think that community will figure this out and will clean up code over time then I'm okay with it.
…On Thu, Oct 4, 2018 at 2:11 PM Bryan C. Mills ***@***.***> wrote:
If they are non-Go files needed for testing some Go package, then go test
all will erroneously report test failures if the package is used.
If they are non-Go files that are also not needed for testing any Go
package, why can't they be pruned out of the Go module in the first place
(e.g. by adding another go.mod)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#28001 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABQDzvS765wSCGIjlGhOb0t_VgB9nwPHks5uhnlwgaJpZM4XHL3B>
.
|
We've only had a few related reports so far, so it doesn't seem to be a major pain point yet (and should only improve over time). Let's keep the validation as-is, and we can revisit if we find that there are a lot more repos that can't be converted to modules. |
Note that #27299 had a very specific use case: Antlr. |
I was hit by this today as well, when trying to get https://github.com/scottshotgg/express_old working with Go modules. Instead of failing with an unzip
|
Running into the same issue trying to go get github.com/influxdata/telegraf:
|
Any chance someone could explain to me why this happens with
I should point out that this only started happening to me since go 1.11.3, 1.11.2 worked fine. |
@guysmoilov That's a mostly-unrelated issue (#29247). |
@bcmills Thanks. So I take it that will be fixed soon? On which version? |
That will be in the 1.11.4 release, which I believe is in final testing now. (Should be out later today.) |
I'm running into this with text files that happen to be in the repo's "docs" folder when I run Is this merely cosmetic at this point? The exit value from |
Hmm; maybe not. On my build server, running
|
See #27063. |
Unfortunately due to a security check in Go modules (as of the latest release), the existance of '..' in a file path in a repository causes the module to be rejected when adding it with `go get`: golang/go#28001 (comment). This renames the testdata directory with the double dots and augments the test code to rename it on the fly back to having two dots to get the appropriate test behavior. This means the tests cannot run on a read-only filesystem but hopefully that is not a requirement.
encountering this error while using go get in one of the files in the docs folder unzip malformed file path invalid char '™' |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.11.1 darwin/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/vit/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/vit/go-code"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.1/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/vit/go-code/devexp/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/6_/htkppg753px1jglygs0c297h0000gn/T/go-build852474991=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
Try consuming a repo which has non-go files that contain ":" in their filenames.
What did you expect to see?
Repo can be imported as a dependency.
What did you see instead?
Error that says:
malformed file path ... invalid char ':'
Notes:
This issue should be similar to the #27642
Would it be possible to relax some of these naming restrictions?
Having to work with third-party package owners for each dependency that might contain these special symbols in filenames sounds like a lot of pain.
The text was updated successfully, but these errors were encountered: