I sent an e-mail to an MS employee about this.

Considering backup files, I note that running Emacs' eshell to overwrite a text file (on Windows) creates a backup.

I don't actually understand what the problem is. In this scenario, the go tool has been asked to create an executable. It is possible that that executable is running which the go tool is also running. This typically happens when using go install to update a binary that happens to be running already. On Unix, this is straightforward: we simply remove the executable and then open the pathname for writing. This does not work on Windows, because Windows does not permit removing a running executable. So on Windows, as a workaround, we rename the executable, because Windows does permit that. Then we proceed as normal. The code in question can be found in cmd/go/internal/work/build.go:

	mayberemovefile(dst)
	df, err := os.OpenFile(dst, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, perm)
	if err != nil && base.ToolIsWindows {
		// Windows does not allow deletion of a binary file
		// while it is executing. Try to move it out of the way.
		// If the move fails, which is likely, we'll try again the
		// next time we do an install of this binary.
		if err := os.Rename(dst, dst+"~"); err == nil {
			os.Remove(dst + "~")
		}
		df, err = os.OpenFile(dst, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, perm)
	}

Your proposal for what we should do instead will not work. We have already tried and failed to remove the executable. It won't help to copy the file first.

We could say that using go install to update a running binary simply fails on Windows, but that seems like a regression from past releases.

I primarily use UNIX based systems, but a quick peer survey returned the conclusion that this behavior was confusing on Windows.

From the perspective of a UNIX user, there is no problem because this approximates the behavior of a UNIX system. But Windows is not a UNIX system and doesn't normally allows files associated with a running process to be altered.

• If I try to delete a running main.exe on Windows, it will fail. This is the expected behavior on a Windows box.
• If I do a go build, that executable is successfully replaced. This is unexpected. You can't uninstall a program, delete it, or write to it, but you can go build it.

It should be the user's responsibility to satisfy the conditions of altering a file on their system. Windows users expect files associated with running processes to be immutable, therefore go build should fail if that precondition is not met.

The community can decide whether this is a compelling issue or not. The goal was to get the data on the issue tracker for those who search for it later.

OK. But the suggestion of copy/delete does not make sense. It sounds like you are suggesting that if go install is used to replace a binary that is currently running, we should simply let the build fail.

This would essentially reverse https://golang.org/cl/5502054 . CC @alexbrainman .

It's worth noting that this change would almost certainly break the special case of go install cmd/go.

we should simply let the build fail.

Yes, that would be the idealistic behavior on a Windows system. Reading the cl gave me some perspective on how long this behavior has been in place, and it does indeed suggest that a change would break things.

Perhaps there is a way to inform the user that a file associated with a running process is being moved, at least then the element of surprise is gone.

Another odd behavior occurs when the backup file main.exe~ already exists. In this case go build main.go fails, saying: go install command-line-arguments: open main.exe: The process cannot access the file because it is being used by another process.

mkdir goissue21997 & cd goissue21997 && echo package main;import "time";import "os";import "fmt"; func main(){println("1");for { time.Sleep(100e6); fmt.Println(os.Executable());};};|gofmt > main.go && go build main.go && start main.exe && echo package main;import "time";import "os";import "fmt"; func main(){println("2");for { time.Sleep(100e6); fmt.Println(os.Executable());};};|gofmt > main.go && go build main.go && start main.exe && go build main.go

we should simply let the build fail.

Yes, that would be the idealistic behavior on a Windows system.

I am not sure I agree that this is ideal. At this moment "go build" and "go install" just silently replaces executable file whether it is running or not - the user does not need to worry if executable is running or not. What you are proposing will make "go build" and "go install" fail occasionally with "executable file is used by another process". People will come here and complain about "go build" is broken sometimes, and we would have to explain the details.

I can see that it confuses knowledgeable users like yourself. But I think this is small price to pay - you could always look at the code or ask here.

Perhaps there is a way to inform the user that a file associated with a running process is being moved, at least then the element of surprise is gone.

How do you propose to do that? We don't want warnings that user should not act upon. And these will only happens occasionally - because there is no reliable way to determine if process is exited or not. I also wouldn't be surprised if we would get many triggers from anti-virus software opening executable file during or after its run.

Another odd behavior occurs when the backup file main.exe~ already exists. In this case go build main.go fails, saying: go install command-line-arguments: open main.exe: The process cannot access the file because it is being used by another process.

Yes that happens when you are trying to actually run new copy of main.exe while previous main.exe process is still running, and we tried our trick of renaming main.exe into main.exe~ and that failed (so we are out of all options). I think the error message is clear about what has happened. So the user has to terminate previous process before trying to build new executable.

I think what we have now is as good as it can be. But if you think you can improve the situation, go ahead and propose you changes. Do not forget, you need to address Ian's comment of:

It's worth noting that this change would almost certainly break the special case of go install cmd/go.

I suggest you find solution to that problem first.

Alex

I suggest you find solution to that problem first.

Given that the behavior existed for 5+ years and this seems to be the only issue logged against it, I don't think the improvement is worth pursuing. Nobody else seems to have an opinion on it except @forskning either, so it's probably best we just leave things as they are in a working state.

@as I will close this as "working as expected". But feel free to reopen if you have some new suggestions.

Alex