`fs::rename` & overwriting existing file


#1

What is the reason behind not returning an Err and silently overwriting the destination file when using the std library function fs::rename?


#2

I’m not sure about windows, but that’s the behaviour of the underlying unix system calls. Trying to check first to see if the destination exists is extra syscalls and subject to races.


#3

thanks, I guess I have to either find a crate or implement the behavior myself


#4

As an aside: destructive rename is often used to atomically replace the contents of an existing file – i.e., write contents into a new (temporary file), and rename over the previous version on completion.

This helps avoid a couple fun outcomes:

  • Partially written files (e.g., on power failure mid-write.)
  • Truncated files (e.g., if you open and attempt to write a file and your filesystem is full.)

Because of this, destructive file rename is a common building block for reliably (and atomically) updating file contents. (in unix-like systems; I’m 99% sure Windows has different semantics here.)


#5

MoveFileEx provides options to rename files in a variety of ways, but the option that libstd chooses to use is the one that mirrors unix semantics (although there are still some differences in how overwriting directories is handled). At least for Windows, it is very easy to wrap MoveFileEx and specify the appropriate options to get the behavior you desire. No idea about other platforms.


#6

On Linux you can use rename2 with the RENAME_NOREPLACE flag, and on macOS you can use renamex_np with the RENAME_EXCL flag.


#7

side question: what happens if something goes wrong (power failure, …) during the rename over operation? or is this a bullet-proof operation somehow guaranteed by filesystem?


#8

It’s supposed to be atomic, so you’ll either see nothing renamed, or the completed replacement. But this hasn’t always been reliable – see this 2009 article on ext4 and data loss.


#9

There was a great paper a few years ago discussing various data vulnerabilities in several popular applications as they relate to assumptions about how filesystems work and crashes: https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf