Bug 5032 – std.file.rename acts differently on Windows and Linux when the target file already exists.

rename, on windows, if the file exists will throw a FileException. However, on Linux, it succeeds.

Could somebody with access to a Windows machine change std.file.rename to overwrite the target? I see in http://msdn.microsoft.com/en-us/library/windows/desktop/aa365240(v=vs.85).aspx that MoveFileEx offers such a flag.

Is that the right thing to do, though? I'd expect the function to throw if the target exists. Doesn't help that the docs for either "copy" and "rename" do not specify what it does in that situation.

(In reply to comment #2) > Is that the right thing to do, though? I'd expect the function to throw if the > target exists. Doesn't help that the docs for either "copy" and "rename" do not > specify what it does in that situation. Yeah I agree. If anything make the forced renaming an option, not a default behavior. That's how most tools work on win32 anyway, dunno about Posix though.

No, rename must clobber. It's the only way things can be done atomically on Unix as far as I can tell. If we have code such as "if (!exists(target)) rename(source, target)" we have a race condition.

I think a clobber option with the default set to "no" would be better. Atomicity is a valid concern, but I don't think the default behavior should imply the risk of accidentally overwriting files. It's too late to change the behavior of "copy", and atomicity does not apply to it anyway.

(In reply to comment #5) > I think a clobber option with the default set to "no" would be better. > Atomicity is a valid concern, but I don't think the default behavior should > imply the risk of accidentally overwriting files. Atomicity is not a concern as much as a gating factor. How to implement the clobber option "no" on Unix? > It's too late to change the behavior of "copy", and atomicity does not apply to > it anyway. This is remove. It must clobber the target on both Windows and Unix.

(In reply to comment #6) > (In reply to comment #5) > > I think a clobber option with the default set to "no" would be better. > > Atomicity is a valid concern, but I don't think the default behavior should > > imply the risk of accidentally overwriting files. > > Atomicity is not a concern as much as a gating factor. How to implement the > clobber option "no" on Unix? > > > It's too late to change the behavior of "copy", and atomicity does not apply to > > it anyway. > > This is remove. It must clobber the target on both Windows and Unix. I mean "This is rename." :o)

(In reply to comment #6) > Atomicity is not a concern as much as a gating factor. How to implement the > clobber option "no" on Unix? Good point. > This is rename. It must clobber the target on both Windows and Unix. Yep, I mentioned copy earlier as they're related. https://github.com/D-Programming-Language/phobos/pull/1198

Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/7d35ad4953d6dd24857bb978219183abce266f4a std.file: Make rename clobber on Windows, adjust docs (Issue 5032) https://github.com/D-Programming-Language/phobos/commit/bba5dbe1c6ab5bb32432d6e7d8fd960713b04163 Merge pull request #1198 from CyberShadow/fix5032 std.file: Fix/document/test clobber behavior for copy and rename (Issue 5032)