In my experience with Go on Windows, the go build
command will create an .exe~
shadow file because of:
- You previously build the runtime and created an .exe.
- You already started/executed the binary.
- That previous execution is still running or some other stupid file lock by windows has occurred.
- You attempt to
go build
again, while the previous binary was still in use.
What happens under the hood is the go build
will rename the existing executed .exe to .exe~ while it is in use, and will place the new binary at .exe for the next execution.
I have always been fascinated by how it does that to files in use, when 20+ years of all other Windows apps returns the dreaded "File In Use" error.
My best guess is that when you execute a go binary, the execution does not place a file lock on the file. So the next build can simply rename the in use one.
During my tests (2014) that new .exe was the latest version and the .exe~ was the previous version that was running.
I did a lot of testing around this as my use case purposely replaced the existing binary upon recompiling.