Can you change what a symlink points to after it is created?
Does any operating system provide a mechanism (system call — not command line program) to change the pathname referenced by a symbolic link (symlink) — other than by unlinking the old one and creating a new one? The POSIX standard does not. Solaris 10 does not. MacOS X 10.5 (Leopard) does not. (I’m tolerably certain neither AIX nor HP-UX does either. Judging from this list of Linux system calls, Linux does not have such a system call either.) Is there anything that does? (I’m expecting that the answer is «No».) Since proving a negative is hard, let’s reorganize the question. If you know that some (Unix-like) operating system not already listed has no system call for rewriting the value of a symlink (the string returned by readlink() ) without removing the old symlink and creating a new one, please add it — or them — in an answer.
What’s wrong with simply relinking? Why not just issue the ln command (or the API equiavalent) overwriting the old link? What problem are you having?
Funny — I’m asking whether there is a system call to do a programming job, and the question is being marked ‘belongs on other site’.
Funny- It was absolutely not clear you were looking for a system call and you just edited the question to add this detail. So how can you expect people to deduct something before you even write it?
@S.Lott: I’m writing up a paper on security and symbolic links. At one point I make the assertion «the actual owner, group, permissions on the symlink itself are immaterial» and the reasoning is that the owner of the symlink can only remove it and not change the value. I’m double checking that there is no way other than by removing the symlink of achieving the effect of ‘rewriting the symlink value’. I’m ignoring direct access to the raw disk and hacking the FS that way — it requires root privilege and my concerns are with non-root users, not with what root can do.
@Pascal: I’m sorry — I didn’t realize it wasn’t clear that I was talking about system calls until people went off on a tangent from what I intended (which was evidently different from what I said). I’m sorry to have misled; it was unintentional.
8 Answers 8
$ ln -sfn source_file_or_directory_name softlink_name Thank you for responding. The -f option means ‘remove the existing destination’ before creating the new one. So, this command achieves the result, but by doing unlink(2) followed by symlink(2) . This is not what the original question was about. Also note that the accepted answer and the next most voted answer both use ln -sf to do the job, but as the strace output shows, it does unlink() and symlink() because there isn’t a system call to modify a symlink.
The ‘n’ switch is important. I struggled with the problem that the symlink was not updated but the command created another link inside the existing one because the ‘no derefencing’ option was not set.
The -n option will make the action become atomic, there will be no unlink get called internally. I have confirmed this by strace, it actually do the ln -s source a_tmp_file && mv -T a_tmp_file symlink .
AFAIK, no, you can’t. You have to remove it and recreate it. Actually, you can overwrite a symlink and thus update the pathname referenced by it:
$ ln -s .bashrc test $ ls -al test lrwxrwxrwx 1 pascal pascal 7 2009-09-23 17:12 test -> .bashrc $ ln -s .profile test ln: creating symbolic link `test': File exists $ ln -s -f .profile test $ ls -al test lrwxrwxrwx 1 pascal pascal 8 2009-09-23 17:12 test -> .profile EDIT: As the OP pointed out in a comment, using the —force option will make ln perform a system call to unlink() before symlink() . Below, the output of strace on my linux box proving it:
$ strace -o /tmp/output.txt ln -s -f .bash_aliases test $ grep -C3 ^unlink /tmp/output.txt lstat64("test", ) = 0 stat64(".bash_aliases", ) = 0 symlink(".bash_aliases", "test") = -1 EEXIST (File exists) unlink("test") = 0 symlink(".bash_aliases", "test") = 0 close(0) = 0 close(1) = 0 So I guess the final answer is «no».
EDIT: The following is copied from Arto Bendiken’s answer over on unix.stackexchange.com, circa 2016.
This can indeed be done atomically with rename(2) , by first creating the new symlink under a temporary name and then cleanly overwriting the old symlink in one go. As the man page states:
If newpath refers to a symbolic link the link will be overwritten.
In the shell, you would do this with mv -T as follows:
$ mkdir a b $ ln -s a z $ ln -s b z.new $ mv -T z.new z You can strace that last command to make sure it is indeed using rename(2) under the hood:
$ strace mv -T z.new z lstat64("z.new", ) = 0 lstat64("z", ) = 0 rename("z.new", "z") = 0 Note that in the above, both mv -T and strace are Linux-specific.
On FreeBSD, use mv -h alternately.
Editor’s note: This is how Capistrano has done it for years now, ever since ~2.15. See this pull request.
It does. But the question might have been perceived as «how do I do that in one step» and then it boils down to the definition of «step» — command line? syscall?
@Pascal: it does. On Solaris, the output from ‘truss ln -s p x’ and ‘truss ln -s -f p x’ shows an unlink() call before the symlink() call in the second case (and a failed symlink() call in the first). I would expect that to apply to most if not all variants of Unix.
+1 to @Taai comment — if dealing with a symlink which dereferences (points to) a directory, you need to specify «-n» to be sure this trick works.
It is not necessary to explicitly unlink the old symlink. You can do this:
ln -s newtarget temp mv temp mylink (or use the equivalent symlink and rename calls). This is better than explicitly unlinking because rename is atomic, so you can be assured that the link will always point to either the old or new target. However this will not reuse the original inode.
On some filesystems, the target of the symlink is stored in the inode itself (in place of the block list) if it is short enough; this is determined at the time it is created.
Regarding the assertion that the actual owner and group are immaterial, symlink(7) on Linux says that there is a case where it is significant:
The owner and group of an existing symbolic link can be changed using lchown(2). The only time that the ownership of a symbolic link matters is when the link is being removed or renamed in a directory that has the sticky bit set (see stat(2)).
The last access and last modification timestamps of a symbolic link can be changed using utimensat(2) or lutimes(3).
On Linux, the permissions of a symbolic link are not used in any operations; the permissions are always 0777 (read, write, and execute for all user categories), and can’t be changed.
@mark4o: The Good — The reference to lchown() and ownership in a sticky-it directory is useful — thanks. I was aware of lchown() and it wasn’t material to my thesis. I was also aware of sticky-bit directories; I think that the ownership is almost a standard consequence of the rules — the difference, and presumably why it is called out, is that normally you can remove a file if you can write to it, and nominally, anyone can write to a symlink because of the 777 permissions, but in this case, the rules are slightly different.
@mark4o: The Not So Good — the command sequence shown doesn’t do what you think it does (at least, in the scenario: set -x -e; mkdir junk; ( cd junk; mkdir olddir newdir; ln -s olddir mylink; ls -ilR; ln -s newdir temp; ls -ilR; mv temp mylink; ls -ilR; ); rm -fr junk ). If you create files oldfile and newfile instead of directories and run the equivalent script (mainly changing olddir to oldfile, newdir to newfile), then you get the effect you were expecting. Just one extra complexity! Thank you for the response.
Just a warning to the correct answers above:
Using the -f / —force Method provides a risk to lose the file if you mix up source and target:
mbucher@server2:~/test$ ls -la total 11448 drwxr-xr-x 2 mbucher www-data 4096 May 25 15:27 . drwxr-xr-x 18 mbucher www-data 4096 May 25 15:13 .. -rw-r--r-- 1 mbucher www-data 4109466 May 25 15:26 data.tar.gz -rw-r--r-- 1 mbucher www-data 7582480 May 25 15:27 otherdata.tar.gz lrwxrwxrwx 1 mbucher www-data 11 May 25 15:26 thesymlink -> data.tar.gz mbucher@server2:~/test$ mbucher@server2:~/test$ ln -s -f thesymlink otherdata.tar.gz mbucher@server2:~/test$ mbucher@server2:~/test$ ls -la total 4028 drwxr-xr-x 2 mbucher www-data 4096 May 25 15:28 . drwxr-xr-x 18 mbucher www-data 4096 May 25 15:13 .. -rw-r--r-- 1 mbucher www-data 4109466 May 25 15:26 data.tar.gz lrwxrwxrwx 1 mbucher www-data 10 May 25 15:28 otherdata.tar.gz -> thesymlink lrwxrwxrwx 1 mbucher www-data 11 May 25 15:26 thesymlink -> data.tar.gz Of course this is intended, but usually mistakes occur. So, deleting and rebuilding the symlink is a bit more work but also a bit saver:
mbucher@server2:~/test$ rm thesymlink && ln -s thesymlink otherdata.tar.gz ln: creating symbolic link `otherdata.tar.gz': File exists which at least keeps my file.
Is there a way to edit a symlink without deleting it first? [duplicate]
Now I want to change the location that the symlink links to. How do I do that? is there a way to do it without deleting it first?
10 Answers 10
You could create the new link with a different name, then move it to replace the old link.
ln -s /location/to/link linkname ln -s /location/to/link2 newlink mv newlink linkname If newlink and linkname are on the same physical device the mv should be atomic.
FYI, i’m sure this works on some os but this didn’t work for me, the move operation just removed the ‘new’ link instead of replacing the old one. i still had to rm first.
@pstanton You mean that mv newlink linkname caused the newlink file to be deleted, but didn’t overwrite the linkname file? Did it do this silently? That seems extremely mysterious.
mv newlink linkname will move your newlink into linkname if they are directories. So this method is not 100% perfect.
Try ln -sf new_destination linkname .
This is non-atomic, though. See my answer for details. I’m not clear whether that’s the poster’s concern or not.
This also won’t work with symlinks pointing to directories. It will just create a new symlink inside the old target directory.
Just change the symlink target:
# ln -sfT /path/to/new/target linkname
This is an instant, atomic change.
-T, —no-target-directory treat LINK_NAME as a normal file always you can brew install coreutils and access the GNU versions with a g prefix, like gln if you want the GNU versions on macOS. saves a lot of headache when there are subtle differences like this.
If the symlink targets are directories, you need to add the -T flag to the mv command, otherwise it moves the new symlink in to the target directory of the old symlink.
Example of atomically switching a website to a new version:
Original setup — website is stored in www1 directory, vhost pointing at www symlink:
Browse to website, see old version.
Put new website files in new www2 directory.
Set up new symlink to new website:
Move www symlink to directory of new website:
Browse to website, see new version immediately.
So apparently the version of mv on my NAS’s microkernel doesn’t support the -T argument. Any alternative suggestions for doing this atomically?
Try creating the symlink with the -f (force) flag. That seems to work. See the answer below: ln -sf new_destination linkname
On OSX, the man page for ln says you can do it like this
ln -shf /location/to/link link name The options are as follows: -F If the target file already exists and is a directory, then remove it so that the link may occur. The -F option should be used with either -f or -i options. If none is specified, -f is implied. The -F option is a no-op unless -s option is specified. -h If the target_file or target_dir is a symbolic link, do not follow it. This is most useful with the -f option, to replace a symlink which may point to a directory. -f If the target file already exists, then unlink it so that the link may occur. (The -f option overrides any previous -i options.) -i Cause ln to write a prompt to standard error if the target file exists. If the response from the standard input begins with the character `y' or `Y', then unlink the target file so that the link may occur. Other- wise, do not attempt the link. (The -i option overrides any previous -f options.) -n Same as -h, for compatibility with other ln implementations. -s Create a symbolic link. -v Cause ln to be verbose, showing files as they are processed.