fs::rename behavior differs on windows

[alexcrichton]

This program will succeed on unix but fail to succeed on windows. The unix behavior is surprising to me!

use std::io::{fs, UserRWX};

fn main() {
    fs::mkdir(&Path::new("test"), UserRWX).unwrap();
    fs::mkdir(&Path::new("test2"), UserRWX).unwrap();
    fs::rename(&Path::new("test"), &Path::new("test2")).unwrap();
}

[abonander]

Actually, looking at the sources, the Windows implementation is surprising to me.

The Windows implementation of fs::rename in libnative/io/file_win32.rs:

pub fn rename(old: &CString, new: &CString) -> IoResult<()> {
    let old = try!(to_utf16(old));
    let new = try!(to_utf16(new));
    super::mkerr_winbool(unsafe {
        libc::MoveFileExW(old.as_ptr(), new.as_ptr(),
        libc::MOVEFILE_REPLACE_EXISTING)
    })
}

And the documentation of MoveFileEx (MoveFileExW is the variant that accepts Unicode filenames):

MOVEFILE_REPLACE_EXISTING

If a file named lpNewFileName exists, the function replaces its contents with the contents of the lpExistingFileName file, provided that security requirements regarding access control lists (ACLs) are met. For more information, see the Remarks section of this topic.

This value cannot be used if lpNewFileName or lpExistingFileName names a directory.

MoveFile can be used on directories, but it cannot overwrite an existing directory, empty or not.

The Unix implementation succeeds because the target directory can be overwritten if it is empty:
http://www.gnu.org/software/libc/manual/html_node/Renaming-Files.html

So fs::rename shouldn't work on directories at all on Windows currently, and the platform-dependent behavior would definitely be frustrating. It should be fixed for Windows, but we'd still have disjoint behavior between platforms. Maybe that part could be fixed with a documentation update.

[brson]

The equivalent python and Java programs succeed on Linux, so perhaps success is the correct result.

[brson]

The 'only if the directory is empty' rule is pretty bizarre. Is that really the cross-platform rule we want?

[alexcrichton]

I've been rethinking the modification to unlink to unify windows/unix due to the non-atomicity of the operation, I'm not sure if we'd want to add more non-atomicity to either windows or unix, so this may just be an unfortunate fact of life.

[brson]

It seems like there's a lot of precedent for unifying I/O semantics from other languages though.

[untitaker]

FWIW Python's rename fails on Windows if the destination path exists: https://docs.python.org/2/library/os.html#os.rename

[alexcrichton]

With the I/O reform having happened since this was opened, I'm going to close this as "not a bug"

[untitaker]

What is the behavior now?

[alexcrichton]

We just shell out to the system call and reexport that behavior.