How can I check if mv is atomic on my fs (ext4)?

The OS is Red Hat Enterprise Linux Server release 6.8.

In general, how can I check this? I have looked around, and didn't find if my OS is standard POSIX.


3 Answers 3


Interestingly enough, it seems the answer may be, "It depends".

To be clear, mv is specified to

The mv utility shall perform actions equivalent to the rename() function

The rename function specification states:

This rename() function is equivalent for regular files to that defined by the ISO C standard. Its inclusion here expands that definition to include actions on directories and specifies behavior when the new parameter names a file that already exists. That specification requires that the action of the function be atomic.

But the latest the ISO C specification for rename() states: The rename function


#include <stdio.h>
int rename(const char *old, const char *new);


The rename function causes the file whose name is the string pointed to by old to be henceforth known by the name given by the string pointed to by new. The file named old is no longer accessible by that name. If a file named by the string pointed to by new exists prior to the call to the rename function, the behavior is implementation-defined.


The rename function returns zero if the operation succeeds, nonzero if it fails, in which case if the file existed previously it is still known by its original name.

Surprisingly, note that there is no explicit requirement for atomicity. It may be required somewhere else in the latest publicly-available C Standard, but I haven't been able to find it. If anyone can find such a requirement, edits and comments are more than welcome.

See also Is rename() atomic?

Per the Linux man page:

If newpath already exists, it will be atomically replaced, so that there is no point at which another process attempting to access newpath will find it missing. However, there will probably be a window in which both oldpath and newpath refer to the file being renamed.

The Linux man page claims the replacement of the file will be atomic.

Testing and verifying that atomicity might be very difficult, though, if that is how far you need to go. You're not clear as to what you mean in your use of "How can I check if mv is atomic". Do you want requirements/specification/documentation that it's atomic, or do you need to actually test it?

Note also, the above assumes the two operand file names are in the same file system. I can find no standard restriction on the mv utility to enforce that.

  • 2
    POSIX doesn't guarantee atomicity either, but Linux, like most unix variants, does, for “native” filesystems such as ext4. Commented Nov 9, 2016 at 23:33
  • 1
    Given that ISO C only defines the behavior of one program and not of a whole system, it would be weird for it to say anything about rename atomicity. Commented Nov 10, 2016 at 12:55
  • 3
    I read "that specification" as referring to the previous sentence ("Its inclusion here... specifies behavior when the new parameter names a file that already exists"), which refers earlier parts of the POSIX doc ("a link named new shall remain visible to other threads throughout... and refer either to the file referred to by new or old..."). In other words, POSIX promises to implement the ISO C standard, and makes additional guarantees beyond what ISO C provides. Does that interpretation help?
    – SimonJ
    Commented Mar 30, 2017 at 19:59
  • 2
    @Tizianoreica I know this is an ancient post, but I just saw your comment and thought I should clarify: The actual filesystem has to be the same for the rename to be atomic. Not just the same type of filesystem. e.g. if you have / as an ext4 fs and /tmp as a different ext4 fs then you cannot atomically mv from one to the other.
    – Wodin
    Commented Feb 13, 2020 at 7:06
  • 1
    @akinomyoga No, it is not. That definition does not address what is observable from outside of the calling thread. Just because the calling thread can only see either success or a failed rename() that leaves the original file unchanged does not mean that an outside observer would never see something like both files existing at once, or even neither file existing, or some other combination. So no, the part you quoted doesn't even imply file system atomicity. Commented Sep 5, 2021 at 10:36

mv is based on rename system call and rename() is atomic. You could look at the manpage rename(2).

You could find answer on Is rename() atomic? on stackoverflow.

What sort of fs, did you use ?

  • fs is ext4 - os already specified. Commented Nov 9, 2016 at 11:02

In addition to checking the systemcalls and their atomicity, maybe inotify-tools can serve as a test, though I am not sure if it is a guaranteed proof of atomicity.

Open 2 shells. Watch the target directory of the move in one of them:

inotifywait -m target/

Move a file into the directory in the other:

mv foobar target/

The inotifywait should show only one line:

target/ MOVED_TO foobar

It seems atomic in comparison to the response to ls target/ and touch target/a, which produce multiline messages like:

# the response to ls target/
target/ OPEN,ISDIR 


I think, at least it shows that asynchronous multiprocess cooperation on files is safe with inotify (practically atomic): in any case you would respond only after inotify gave the final signal after the operation. For example, a producer-consumer setup can be implemented easily and safely with inotify.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .