Golang compilation error copying /tmp/go-build069786374/b001/exe/a.out: No such file or directory solution

Problem: Golang compilation error on linux virtual machine copying /tmp/go-build069786374/b001/exe/a.out: No such file or directory

Reason: The shared directory of windows and linux virtual machine is unstable.

Solution: Restart the linux virtual machine and re-share the directory to compile and pass

The detailed process is as follows:

Today, when the source file main.go of the build command was generated, an error was reported:

go build command-line-arguments: copying /tmp/go-build042781492/b001/exe/a.out: open main: text file busy

The meaning is obvious. After the build is completed, when the compiled file is overwritten with the executable file main that was generated before, it is found that the main file is occupied and has not been released and cannot be overwritten.

Because I have run the main, and then I modified the code, the problem occurred during rebuild, logically speaking, this kind of problem should not occur, after thinking about it, because I used the virtual machine + shared folder Linux running in form has been pitted by this file system before, and the probability of this accident is also the problem.

I will test on windows first.

package main

import (
    "fmt"
    "time"
)

func main() {
    time.Sleep(30*time.Second)
    fmt.Println("2")
}

The thing to test is: when an executable file is running, modify the code to see if it can compile successfully and overwrite the original executable file.

go build main.go

Run the file main.exe

Modify the code fmt.Println("3")

New window go build main.go

Found that the compilation passed, no error was reported, run main.exe

The result is that the first output is 2 and the second output is 3, which proves to be normal.

So, I went back to Linux and created the test code outside the shared directory. My shared directory is /data/www/

cd /data
mkdir test
cd test
go mod init test
vi main.go

Enter the above test code

Performing the same test steps, it is found that it is normal, it seems that this reason is caused by the virtual machine shared directory.