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.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Interestingly enough, it seems the answer may be, “It depends”.
To be clear, mv is specified to
The
mvutility shall perform actions equivalent to therename()
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:
7.21.4.2 The
renamefunctionSynopsis
#include <stdio.h> int rename(const char *old, const char *new);Description
The
renamefunction causes the file whose name is the string pointed to byoldto be henceforth known by the name
given by the string pointed to bynew. The file namedoldis no
longer accessible by that name. If a file named by the string pointed
to bynewexists prior to the call to therenamefunction, the
behavior is implementation-defined.Returns
The
renamefunction 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
newpathalready exists, it will be atomically replaced, so that
there is no point at which another process attempting to access
newpathwill find it missing. However, there will probably be a
window in which botholdpathandnewpathrefer 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.
Method 2
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 ?
Method 3
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 target/ ACCESS,ISDIR target/ CLOSE_NOWRITE,CLOSE,ISDIR
PS
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.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0