Can you change what a symlink points to after it is created?
Asked Answered
V

8

144

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. Mac OS 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.

Vidicon answered 23/9, 2009 at 14:58 Comment(7)
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?Bullhead
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'.Vidicon
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?Spotted
@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.Vidicon
@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.Vidicon
Another way to do it is to create a new symbolic link and then rename() it (it will replace the old one).Oddment
@Oddment That's not actually editing it.Standby
S
114

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

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", {st_mode=S_IFLNK|0777, st_size=7, ...}) = 0
stat64(".bash_aliases", {st_mode=S_IFREG|0644, st_size=2043, ...}) = 0
symlink(".bash_aliases", "test")        = -1 EEXIST (File exists)
unlink("test")                          = 0
symlink(".bash_aliases", "test")        = 0
close(0)                                = 0
close(1)                                = 0

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", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
lstat64("z", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 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.

This is how Capistrano has done it for years now, ever since ~2.15. See this pull request.

Spotted answered 23/9, 2009 at 14:59 Comment(9)
Doesn't the '-f' option force 'ln' to do the unlink() then symlink() system calls?Vidicon
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?Botswana
I've just noticed that you added syscall wording to your question ;-)Botswana
About the --force option, the man says "remove existing destination files". I don't know if this implies a call to unlink().Spotted
@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.Vidicon
@HermannIngjaldsson not to bring this back from the dead but that won't work (at least on Linux) if you the destination file is an existing symlink. The symlink will still point to the original file. Very surprising to me.Mambo
+1 to @Erudite comment - if dealing with a symlink which dereferences (points to) a directory, you need to specify "-n" to be sure this trick works.Oraleeoralia
could you clarify what the -T option does, just so it is easier to understand? (treats as file, not directory)Stank
That document doesn't actually say that renaming a temporary symbolic link to another existing symbolic link will edit the symbolic link.Standby
E
185

Yes, you can!

ln -sfn source_file_or_directory_name softlink_name
Erudite answered 2/7, 2012 at 16:46 Comment(4)
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.Vidicon
The -n seems to be required when the original link goes to a directory instead of a file.Commeasure
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.Pitsaw
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.Ernestineernesto
S
114

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

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", {st_mode=S_IFLNK|0777, st_size=7, ...}) = 0
stat64(".bash_aliases", {st_mode=S_IFREG|0644, st_size=2043, ...}) = 0
symlink(".bash_aliases", "test")        = -1 EEXIST (File exists)
unlink("test")                          = 0
symlink(".bash_aliases", "test")        = 0
close(0)                                = 0
close(1)                                = 0

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", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
lstat64("z", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 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.

This is how Capistrano has done it for years now, ever since ~2.15. See this pull request.

Spotted answered 23/9, 2009 at 14:59 Comment(9)
Doesn't the '-f' option force 'ln' to do the unlink() then symlink() system calls?Vidicon
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?Botswana
I've just noticed that you added syscall wording to your question ;-)Botswana
About the --force option, the man says "remove existing destination files". I don't know if this implies a call to unlink().Spotted
@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.Vidicon
@HermannIngjaldsson not to bring this back from the dead but that won't work (at least on Linux) if you the destination file is an existing symlink. The symlink will still point to the original file. Very surprising to me.Mambo
+1 to @Erudite comment - if dealing with a symlink which dereferences (points to) a directory, you need to specify "-n" to be sure this trick works.Oraleeoralia
could you clarify what the -T option does, just so it is easier to understand? (treats as file, not directory)Stank
That document doesn't actually say that renaming a temporary symbolic link to another existing symbolic link will edit the symbolic link.Standby
W
15

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.

Williawilliam answered 24/9, 2009 at 16:35 Comment(2)
@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.Vidicon
@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.Vidicon
R
3

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.

Richelle answered 25/5, 2014 at 13:32 Comment(1)
Using a -f or --force option is always a bit dangerous; it presumes the user knows what they're about. It is doubly lethal if you use it habitually (rm -fr … every time is dangerous).Vidicon
D
1

Wouldn't unlinking it and creating the new one do the same thing in the end anyway?

Dani answered 23/9, 2009 at 14:59 Comment(6)
Why unlink in the first place? Why not simple overwrite it?Bullhead
The net result is approximately the same - but the owner and group and last modified times (and probably inode number) would all be different, in general.Vidicon
@S.Lott: what system call does the 'overwrite'? In POSIX, there is no such call. In Solaris and MacOS X, there is no such call. Is there a call to do that on ... Linux, AIX, HP-UX, anything else that looks like Unix? Windows doesn't really have symlinks in the same way, AFAICT, so it is not critical to my analysis - but information about the equivalent Windows API would be useful.Vidicon
@Jonathan Leffler: Ummm.... the ln --force command will absolutely overwrite an existing link.Bullhead
Guys, I think you are talking at cross purposes. S.Lott is discussing an executable ln (1), while matt b. is discussing the fact that symlink (2) does not support overwriting. You are both right, and I would suggest that looking at the implementation of ln (1) would give the most idomatic way of accomplishing the unlink-relink procedure.Ferrin
Actually I just didn't know that ln had a --force argument :(Dani
D
1

Just in case it helps: there is a way to edit a symlink with midnight commander (mc). The menu command is (in French on my mc interface):

Fichier / Éditer le lien symbolique

which may be translated to:

File / Edit symbolic link

The shortcut is C-x C-s

Maybe it internally uses the ln --force command, I don't know.

Now, I'm trying to find a way to edit a whole lot of symlinks at once (that's how I arrived here).

Danille answered 7/7, 2014 at 18:11 Comment(2)
Have you verified what MC does behind the scenes? I'd lay odds that in fact it does an unlink() followed by a symlink(), simply because that's what Unix-like systems provide.Vidicon
No, I haven't checked. And yes, it is quite probable that it does as you say, in fact.The fact that I edit a textbox gives the feeling that I am actually editing the symlink target, but I've probably been fooled...Danille
B
1

Technically, there's no built-in command to edit an existing symbolic link. It can be easily achieved with a few short commands.

Here's a little bash/zsh function I wrote to update an existing symbolic link:

# -----------------------------------------
# Edit an existing symbolic link
#
# @1 = Name of symbolic link to edit
# @2 = Full destination path to update existing symlink with 
# -----------------------------------------
function edit-symlink () {
    if [ -z "$1" ]; then
        echo "Name of symbolic link you would like to edit:"
        read LINK
    else
        LINK="$1"
    fi
    LINKTMP="$LINK-tmp"
    if [ -z "$2" ]; then
        echo "Full destination path to update existing symlink with:"
        read DEST
    else
        DEST="$2"
    fi
    ln -s $DEST $LINKTMP
    rm $LINK
    mv $LINKTMP $LINK
    printf "Updated $LINK to point to new destination -> $DEST"
}
Baliol answered 26/11, 2017 at 22:19 Comment(1)
Thank you for the effort. This doesn't meet my requirement of being a C language system call. There are numerous way to change a link as long as you have write permission on the directory holding the link (which this requires). There no ways that I know of, even now, to change the value of a symlink without doing unlink() and symlink() with the new value, which is what goes on behind the scenes with your code. Personally, I'd have the function insist on exactly two (or perhaps a multiple of two) arguments and bail if the invocation was not correct. That's a particular perspective, though.Vidicon
I
0

You can modify the softlink created once in one of the two ways as below in Linux

  1. one is where you can remove existing softlink with rm and again create new softlink with ln -s command .
  2. However this can be done in one step , you can replace existing softlink with updated path with "ln -vfns Source_path Destination_path" command.

Listing initial all files in directory

$ ls -lrt 
drwxrwxr-x. 3 root    root      110 Feb 27 18:58 test_script
$

Create softlink test for test_script with ln -s command.

$ ln -s test_script test
$ ls -lrt
drwxrwxr-x. 3 root    root      110 Feb 27 18:58 test_script
lrwxrwxrwx. 1 root    root       11 Feb 27 18:58 test -> test_script
$

Update softlink test with new directory test_script/softlink with single command

$ ln -vfns test_script/softlink/ test
'test' -> 'test_script/softlink/'
$

List new softlink location

$ ls -lrt
lrwxrwxrwx. 1 root    root       21 Feb 27 18:59 test -> test_script/softlink/
$

ln --help

-v, --verbose print name of each linked file

-f, --force remove existing destination files

-n, --no-dereference treat LINK_NAME as a normal file if it is a symbol

-s, --symbolic make symbolic links instead of hard links

Incomplete answered 28/2, 2022 at 5:45 Comment(1)
Thank you, but the question says "Does any operating system provide a mechanism (system call — not command line program) …". What you describe are command-line programs doing the job, and AFAICT they are simply using the unlink() and symlink() system calls, not some hypothetical 'altersymlink()` system call.Vidicon

© 2022 - 2024 — McMap. All rights reserved.