Re: [PATCH] Add a "-h" flag to mv

From: Jilles Tjoelker <jilles_at_stack.nl>
Date: Wed, 29 Aug 2012 12:02:47 +0200
On Tue, Aug 28, 2012 at 10:58:09AM -0400, John Baldwin wrote:
> I have a use case at work where I need to be able to update a symlink
> that points to a directory atomically (so that it points to a new
> directory).  To give a conrete example, suppose I have two directories
> 'foo' and 'bar', and a symlink 'a' that I wish to atomically flip from
> 'foo' to 'bar'.

> Using 'ln -shf bar a' is not atomic as it uses separate unlink() and
> symlink() system calls, so there is a race where another thread may
> encounter ENOENT while traversing 'a'.

> The approach we used was to create a new symbolic link 'a.new' (e.g.
> via 'ln -s bar a.new') and then use rename() to rename 'a.new' on top
> of 'a'. Normally to do an atomic rename from userland one would use
> 'mv', but 'mv a.new a' doesn't do that.  Instead, it moves 'a.new'
> into the directory referenced by the 'a' symlink.  At work we have
> resorted to invoking python's os.rename() in a one-liner to handle
> this.

> While rehashing this discussion today it occurred to me that a -h flag to
> mv would allow it to work in this case (and is very similar to how ln treats
> its -h flag).  To that end, I have a patch to add a new -h flag to mv that
> allows one to atomically update a symlink that points to a directory.  I
> could not find any other mv commands that have adopted a -h (or a different
> flag that accomplishes the same task).  Given that it functions identically
> to the -h flag for ln, -h seemed the "logical" choice.  Any objections?

GNU coreutils mv (and also cp/install/ln) appears to use
-T/--no-target-directory for a similar purpose: -T prevents the target
being treated as a directory (whether it is a symlink or not).

-- 
Jilles Tjoelker
Received on Wed Aug 29 2012 - 08:02:48 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:30 UTC