I explicitly mentioned the possibility of filing an issue on the SO answer:
If you can't configure the filesystem to support locking and it isn't practical for you to work within a different filesystem that does, please file an issue at https://golang.org/issue/new, and mention issue #37461 (which is closely related) in the issue description.
So I think it's fine to keep this issue open. Honestly, I think we should probably proceed without file-locking when the go.mod and go.sum files cannot be locked — they're less prone to race conditions than, say, the module cache (which must support file-locking because it is much harder to fix if it becomes corrupted, and is implicitly modified much more frequently).
Now that the go command defaults to -mod=readonly, I wonder if this file-locking has outlived its usefulness. Maybe we should stop using file-locking in the main module (and only use it within the module cache). (CC @matloob)
On the other hand, the locking errors that show up in the gopls tests are probably actual real/write races, and they can probably at least show up as corrupted diagnostics in actual use. 🤔
What version of Go are you using (
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
What did you do?
I tired to create a module for my new golang project using
go mod init github.com/ayush/secure-api
What did you expect to see?
I expected of successfully creation of module for my project.
What did you see instead?
Error I got:
go: RLock /storage/8D8B-150E/Go/secure-api/go.mod: function not implemented
The text was updated successfully, but these errors were encountered: