Windows os.Rename bad

[gopherbot]

by kfox1111:

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull", "hg update default", rebuild, and
retry
what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. os.Rename('foo', 'file.that.already.exists')

What is the expected output?
The file be overwritten.

What do you see instead?
Error that file exists.

Which compiler are you using (5g, 6g, 8g, gccgo)?
8g

Which operating system are you using?
Windows

Which revision are you using?  (hg identify)
Newest weekly.

Please provide any additional information below.

[4ad]

Comment 1:

Package os provides a consistent interface to the system, but the behavior of the
implementation might vary between systems due to system-specific rules. This is how
Windows rename works, I'm not sure it's our job to "fix" it.

[4ad]

Comment 2:

Package os provides a consistent interface to the system,
but the behavior of the implementation might vary between
systems due to system-specific rules.  This is how Windows
rename works, I'm not sure it's our job to "fix" it.

[ianlancetaylor]

Comment 3:

As far as I know, there is no way to handle os.Rename such that it is equivalent on
Windows and POSIX systems.  In particular, on POSIX os.Rename is atomic, in the sense
that if the destination path already exists, any other process can always open the
destination path and get either the old file or the new file.  Since we can't provide
identical semantics on different operating systems, I don't think we should try to go
beyond what the OS provides.  There is no one right choice.

Status changed to WorkingAsIntended.

[minux]

Comment 4:

Issue #5620 has been merged into this issue.

[gopherbot]

Comment 5 by MartyMacGyver:

I recommend this bug be reopened and reconsidered. Other languages have encountered and
tackled this problem successfully in Windows. As one example, the report of the same
issue in Python led to a detailed discussion and ultimately had a successful resolution
(http://bugs.python.org/issue8828). The resolution of this bug in other Go projects
follows the same pattern - effectively creating an os.Replace() function for this
circumstance, using the Windows MoveFileEx api. Whether os.Rename() is enhanced to
properly handle Windows cases or a new os.Replace() function is created that satisfies
the same criteria, it would prevent everyone from re-inventing the same wheel virtually
the same way simply to sidestep this bug.

[alexbrainman]

Comment 6:

MartyMacGyver, if you are asking for new os function, you should create new issue.
Behaviour of os.Rename is not up for a discussion.
Alex

[gopherbot]

Comment 7 by MartyMacGyver:

Understood. I've created a new issue #8914 for this purpose.