I have two directories in the same parent directory. Call the parent directory base and the children directories alpha and bravo. I want to replace alpha with bravo. The simplest method is:
rm -rf alpha mv bravo alpha
The mv command is atomic, but the rm -rf is not. Is there a simple way in bash to atomically replace alpha with bravo? If not, is there a complicated way?
By the by, it’s not an insurmountable problem if the directory doesn’t exist for a short period. There’s only one place that tries to access alpha, and it checks if alpha exists before doing anything critical. If not, it gives an error message. But it would be nice if there was a way to do this. 🙂 Maybe there’s some way to modify the inodes directly, or something…
You can do this if you use symlinks:
Let’s say alpha is a symlink to directory alpha_1, and you want to switch the symlink to point to alpha_2. Here’s what that looks like before the switch:
$ ls -l lrwxrwxrwx alpha -> alpha_1 drwxr-xr-x alpha_1 drwxr-xr-x alpha_2
To make alpha refer to alpha_2, use ln -nsf:
$ ln -nsf alpha_2 alpha $ ls -l lrwxrwxrwx alpha -> alpha_2 drwxr-xr-x alpha_1 drwxr-xr-x alpha_2
Now you can remove the old directory:
$ rm -rf alpha_1
Note that this is NOT actually a fully atomic operation, but it does happen very quickly since the “ln” command both unlinks and then immediately recreates the symlink. You can verify this behaviour with strace:
$ strace ln -nsf alpha_2 alpha ... symlink("alpha_2", "alpha") = -1 EEXIST (File exists) unlink("alpha") = 0 symlink("alpha_2", "alpha") = 0 ...
You can repeat this procedure as desired: e.g. when you have a new version, alpha_3:
$ ln -nsf alpha_3 alpha $ rm -rf alpha_2
The final solution is combining the symlink- and the rename-approach:
mkdir alpha_real ln -s alpha_real alpha # now use "alpha" mkdir beta_real ln -s beta_real tmp # atomically rename "tmp" to "alpha" # use -T to actually replace "alpha" instead of moving *into* "alpha" mv -T tmp alpha
Of course, the application accessing alpha has to be able to deal with symlinks changing in the path.
If you mean atomic across both operations, I don’t believe so. The closest would be:
mv alpha delta mv bravo alpha rm -rf delta
but that would still have a small window where alpha didn’t exist.
To minimize the likelihood of anything trying to use alpha while it’s not there you could (if you have the authority):
nice --20 ( mv alpha delta ; mv bravo alpha ) rm -rf delta
which will crank up your process priority substantially while the
mv operations are happening.
If, as you say in your addendum, there’s only one place that checks alpha and it errors if it’s not there, you could change that code to not error immediately, but try again in a short time (easily sub-second for two
mv operations) – these retries should alleviate any problem unless you’re replacing alpha very frequently.
Use a separate, guaranteed atomic, operation to act as a semaphore.
So, if the creating and removing a file operations are atomic:
1) create a file called “semaphore”.
2) If and only if that is successful (no conflict with existing file), do the operation (either process alpha or move the directory, depending on the process)
3) rm semaphore.
Picking up on David’s solution here, which is fully atomic … the only problem you’d run into is that the
-T option for
mv is non-POSIX, and so certain POSIX OSes may not support it (FreeBSD, Solaris, etc. … http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html). With slight modification, this approach can be altered to be fully atomic, and portable across all POSIX OSes:
mkdir -p tmp/real_dir1 tmp/real_dir2 touch tmp/real_dir1/a tmp/real_dir2/a # start with ./target_dir pointing to tmp/real_dir1 ln -s tmp/real_dir1 target_dir # create a symlink named target_dir in tmp, pointing to real_dir2 ln -sf tmp/real_dir2 tmp/target_dir # atomically mv it into ./ replacing ./target_dir mv tmp/target_dir ./
The SQLite documentation section File Locking and Concurrency in SQLite Version 3 has a well-written description of its escalating locking protocol to control concurrent reading, exclusive writing, and rollback after a crash. Some of those ideas apply here.
This should do the trick:
mkdir bravo_dir alpha_dir ln -s bravo_dir bravo ln -s alpha_dir alpha mv -fT bravo alpha
strace mv -fT bravo alpha shows:
which looks pretty atomic to me.
I don’t believe there’s any atomic way to do this. Your best bet is to do something like this:
mv alpha delme mv bravo alpha rm -rf delme
Even if you were accessing the inodes directly there would still be no way to atomically swap the inode values in user-space.
Worrying about the atomic nature of the operation is meaningless. The thing is, the access to alpha by the other task will not be atomic anyway.
Oddthinking’s semaphore approach is the only way to go.
If you can’t modify the other task then you’ll have to ensure it’s not running before doing the replacement.
Something to keep in mind is that if your process has any of the files in alpha open when this move/delete occurs the process will not notice and any data written will be lost when the file is closed and finally removed.
mv and ln can be used for atomic operations. I’ve used ln(1) to deploy web applications atomically.
The correct way to replace a symlink is with ln -nsf
ln -nsf <target> <link_name>
$ mkdir dir1 $ mkdir dir2 $ ln -s dir1 mylink $ ls -l mylink lrwxrwxrwx 1 phil phil 4 Nov 16 14:45 mylink -> dir1 $ ln -nsf dir2 mylink $ ls -l mylink lrwxrwxrwx 1 phil phil 4 Nov 16 14:46 mylink -> dir2
Why don’t you just do something like:
rm -rf alpha/* mv bravo/* alpha/ rm -rf bravo/
That would mean that everything in alpha is destroyed, alpha never gets deleted, and all the contents get moved.