A similar failure with ':' after workaround:

$ go get lab.nexedi.com/kirr/neo/go@t
go: downloading lab.nexedi.com/kirr/neo v1.8.2-0.20200915132355-8783ff63fc24
go get lab.nexedi.com/kirr/neo/go@t: create zip: malformed file path "t/time/time-soct12-neo1-neo2.txt-tgro20-txc:200µs4f": invalid char ':'

This is working as intended I'm afraid.

There are a number of constraints on file and directory names within modules. These constraints ensure that module zip files can be extracted consistently on a wide variety of file systems.

If you don't want to include those files in the module archive, you can add an empty go.mod file to the parent directory.

oh, I see. Ok...

I know this issue is closed. So perhaps this should be a new issue.

@jayconrod I was just wondering if there is a go get flag to use git clone directly instead of downloading Go modules as ZIP files. The constraints listed in https://golang.org/ref/mod#zip-path-size-constraints are quite restrictive (e.g. max 500 MB), so being able to handle Go modules that fail to satisfy one of these constraints would be desirable; e.g. go get -zip=false github.com/foo/bar

Cheers,
Robin

@mewmew Sorry, no. While the go command can clone repositories using git in direct mode (with GOPROXY=direct or with an appropriate GONOPROXY setting), the same restrictions apply.

The goal here is to ensure that modules can be extracted and used consistently on a wide variety of platforms and file systems.

The constraint you mentioned in particular (500MB size limit) is nearly always enough for source code. You can exclude directories containing test data and other large files by placing a go.mod file (even an empty one) at the top of it.

Thank you for the added background information @jayconrod.

Cheers,
Robin

Unfortunately, I have unit tests that need to exactly reproduce with a test file that ends in .. This file name replicates the situation on a product and our tests need to reproduce this situation exactly. The product is a Linux-only product, so we really don't care about the "needs to work across all file systems". At the moment, Go breaks our product development. Thank you so much.

@thediveo as a workaround you could create those files dynamically in the test setup, i.e. those files with Go-incompatible names are never commited into the repo.

True, but that's very cumbersome and error prone.