3

Because rename(2) is called by mv, is it safe to assume the following would be atomic?

$ mv /home/me/someDir /tmp/toBeDeleted
$ rm -rf /tmp/toBeDeleted
2

If the directories are on the same hardware partition mounted as a single filesystem, then moving something is actually just renaming it to a different path. However, if they are not, then each file inside may need to be read in and copied out, so no part of the move would be atomic. As Gilles points out, POSIX stipulates this is the case for discrete filesystems.

Excepting that, a quick check with strace confirms mv does use the rename() system call (not to be confused with rename, the command line utility). That would make mving a directory atomic from a userspace perspective. The rename() system call will throw an EBUSY error if:

oldpath or newpath is a directory that is in use by some process (perhaps as current working directory, or as root directory, or because it was open for reading) or is in use by the system (for example as mount point), while the system considers this an error. (Note that there is no requirement to return EBUSY in such cases—there is nothing wrong with doing the rename anyway—but it is allowed to return EBUSY if the system cannot otherwise handle such situations.)

From man 2 rename. The connection to "atomicity" here is that you can't interrupt another process working in the directory, and another process can't interrupt this -- it'll end up with an invalid path/not found type error if you beat it in the chase.

  • You're right, I did mean rename(2). Great answer and thanks for the help. – jibsales Jan 7 '15 at 20:42
  • 1
    Not if /home/me and /tmp are on different filesystems! – Gilles Jan 7 '15 at 23:29
  • @Gilles Arghhh... – goldilocks Jan 8 '15 at 2:47
  • To be on the safe side, I'd move it to the same directory, with a suffix - maybe using a name that's probably not in use, such as /home/me/.todelete~ or similar (a dot is a good idea to hide it from users using ls, and most of other tools also have an option to ignore dotted files. Tilde also suggests it's a sort of a backup/temporary file). /tmp/ is almost guaranteed to be on a different filesystem: it's usually a ramfs, and even if it isn't, /home/ may be a separate partition. – orion Jan 8 '15 at 8:13
3

The mv command calls the rename system call, which is guaranteed to be atomic. However, there are two exceptions:

  • If the source and the destination are on different filesystems, which is relatively common for /home vs. /tmp, then rename fails, and mv then works by copying the source tree to the destination and then removing the source tree. This is evidently not atomic.
  • There are filesystems where rename is not atomic, such as certain implementations of NFS. On any “normal” local filesystem, rename is atomic.
  • Valid points. I'm working within a Debian VM at the moment, but these are good things to know for future endeavors. – jibsales Jan 8 '15 at 1:40
1

Both answers say essentially the same thing, but only focus on one aspect of removal.

If you have a shell whose working directory is within the renamed/moved directory tree, it will continue to see and use those files until they are actually removed. Because of this, the shell will see the files in varying states of deletion, and consequently, the rename/move (while may be "atomic" in itself) is not a atomic form of deletion from the point of view of all users of the files. It only affects users whose shell is outside the directory tree from the outset.

The shell maintains its own information regarding which directory it is in. That is because in some configurations you may change the current directory into one where you have no permissions to read the chain of directory information needed to determine the actual path, e.g., by following a symbolic link into a protected directory.

POSIX is vague on the reason for the behavior, but does point out the behavior for pwd (shell built-in) and cd (shell built-in).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.