I think you're after go mod verify:

$ go help mod | grep verify
	verify      verify dependencies have expected content

I believe that other commands like go get and go build will only check a module's contents when downloading the module for the first time. Doing that again any time a build happens, or any time a module's dependencies are queried, could be pretty expensive and hurt incremental builds.

This is explained a bit in go help modules:

No matter the source of the modules, the go command checks downloads against known checksums, to detect unexpected changes in the content of any specific module version from one day to the next.

Also:

The reason I raise this is that I on rare occasions have seen empty cache folders. I'm not able to give further details about when/how this happens, but for me, it happens only on MacOS. In most situations, this will be visible (break the build), but not always.

If that is your problem, I think we should investigate it. Until the bug is investigated, go mod verify is a manual alternative.

CC @bcmills @jayconrod

go mod verify

I did not know about that one. Running that one on the project above gives:

github.com/bep/testmodlib v1.0.0: dir has been modified (/Users/bep/go/pkg/mod/github.com/bep/testmodlib@v1.0.0)

But I think this boils down to this:

• I don't think you can ever give any 100% guarantee that your "download to cache" works on all platforms without additional checks.
• Adding go mod verify as part of the build may be too heavy as part of your daily development, but certainly fine for CI/release builds.
• Assuming "my empty folders" are empty after a `go mod download´, maybe check the folder hash after it is written ...

Most of what you describe is working as intended.

The integrity of module zip files is verified when they are downloaded and extracted into the cache. The go command computes a cryptographic sum of the contents of each zip file and compares that to the corresponding entry in go.sum for the main module. If there is no entry in go.sum, the go command retrieves the expected sum from sum.golang.org (unless the module is in GOPRIVATE or GONOSUMDB). So we're pretty confident about the integrity of each module, when it's ingested into the cache.

Files and directories within the cache are marked read-only to prevent accidental changes (unless the -modcacherw flag is used). go mod verify may be used to compare extracted zip contents with the zip files they came from, but it would expensive to do it on every build, since it reads a lot of files that aren't normally touched.

The reason I raise this is that I on rare occasions have seen empty cache folders. I'm not able to give further details about when/how this happens, but for me, it happens only on MacOS. In most situations, this will be visible (break the build), but not always.

Assuming "my empty folders" are empty after a `go mod download´, maybe check the folder hash after it is written ...

Could you explain more? Is the whole cache empty ($GOPATH/pkg/mod)? Or a specific module directory (e.g., $GOPATH/pkg/mod/golang.org/x/tools@v0.0.0-something-something)? Or another directory? Is it right after a module is downloaded or some time later?

The go command shouldn't automatically remove anything from the module cache. go clean -modcache is the only command that would do that.

cc @bcmills @matloob

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)