What happens to a symbolic link when the original file is replaced?

Question

I have update software in /opt/minergate-cli. I've renamed the directory minergate-cli to minergate-old with an mv command, then installed a newer version of the software giving the same directory name.

Assuming I had an old program and now a new program by the same name, that being "minergate" what happens to any symbolic links pointing to the program minergate?

Are they pointing to the original program living in minergate-old, or did the link move to the new program minergate.cli?

Solution 1

Summary

• Symlinks do not follow the files to which they point. If you have link_file -> original_file and you do mv original_file original_file.backup the link_file will be broken

• If you recreate original filename ( which is what OP did ) the symlink will work again

• If you have to make link_file -> original_file.backup, you have to delete link_file and create it again, pointing to new filename

Answer

What happens to symlink if we rename a file ?

Once you move a file to which symlink points, symlink is broken aka dangling symlink. You have to delete it and create new one if you want to point to the new filename.

For example, let's create a symlink to file:

$ ln -s testfile.txt mysymlink
$ ls -l mysymlink
lrwxrwxrwx 1 adm adm 12 Dec  8 13:28 mysymlink -> testfile.txt

Now let's rename the file. You will see symlink still points to the pathname that no longer exists (which is important, file exists, pathname - does not):

$ mv testfile.txt testfile.txt.bak
$ ls -l mysymlink
lrwxrwxrwx 1 xie xie 12 Dec  8 13:28 mysymlink -> testfile.txt
$ cat mysymlink
cat: mysymlink: No such file or directory

How to fix a broken symlink ?

If you can rename file to original pathname, the symlink will start working.

$ mv testfile.txt.bak testfile.txt $ cat mysymlink one two three

If renaming is not an option and you may not rename the file, create a new symlink and delete the old one.

# break the symlink
$ mv  testfile.txt testfile.txt.bak
$ cat mysymlink
cat: mysymlink: No such file or directory
# remove the old symlink
$ rm mysymlink
# create symlink with same filename but pointing to new pathname
$ ln -s testfile.txt.bak mysymlink
$ cat mysymlink 
one two three

OP question: Did the link move to the new program minergate.cli?

If the symlink target /opt/minergate-cli has been re-created when new version of application was installed, the symlink will point to new file. If the new file has different filename, then symlink will be broken. Symlinks do not follow filename if filename was moved, as in OP's example when they did mv /opt/minergate-cli /opt/minergate.old , so symlink will still keep pointing to /opt/minergate-cli regardless if that file exists or not.

See also

• https://unix.stackexchange.com/a/18365/85039

Solution 2

A symlink just holds the name of the file that it points to. (hint, do ls -l symlink and note its file size). If you delete the target file, but then create a new file with the same name, the symlink will happily keep working, referring to the new file contents:

$ echo "first file" > file
$ ln -s file symlink
$ ls -l symlink
lrwxrwxrwx 1 jackman jackman 4 Oct 23 23:33 symlink -> file
# ...........................^=size ...................^^^^ target is 4 chars
$ cat symlink
first file
$ mv file file.old
$ echo "this is the second" > file
$ cat symlink
this is the second

---

You may be think about a "hard" link, which refers to the target file's inode:

$ echo "first line" > file
$ ln file hardlink
$ ls -li hardlink file
1078415 -rw-r--r-- 2 jackman jackman 11 Oct 23 23:38 file
1078415 -rw-r--r-- 2 jackman jackman 11 Oct 23 23:38 hardlink
$ cat hardlink
first line
$ mv file file.old
$ echo "this is the new contents" > file
$ cat hardlink
first line
$ ls -li hardlink file file.old
1059446 -rw-r--r-- 1 jackman jackman 25 Oct 23 23:39 file
1078415 -rw-r--r-- 2 jackman jackman 11 Oct 23 23:38 file.old
1078415 -rw-r--r-- 2 jackman jackman 11 Oct 23 23:38 hardlink

here hardlink is the same file as the original file file.

Comments

[NZ Dev]

This answer is opposite the other answer who is right? Your answers say you do not have to recreate the symlink. the other says you have to recreate the symlink.

[NZ Dev]

This answer is opposite the other answer who is right? Your answer says you have to recreate the symlink. the other says you do not have to recreate the symlink.

[Sergiy Kolodyazhnyy]

If you search online for "broken symlink" you'll see multiple other answers like mine, unix.stackexchange.com/a/407480/85039. And especially this one: unix.stackexchange.com/a/407480/85039 this one is written by Gilles who is very highly knowledgeable and respected in Linux community, his answer would agree with mine

[Sergiy Kolodyazhnyy]

Sorry, here's the proper link to Gille's answer unix.stackexchange.com/a/18365/85039 Kinda hard to type on phone

[Sergiy Kolodyazhnyy]

@NZDev And I think you may have misunderstood what what my and Glenn's answers are showing. We're not talking about entirely opposite things. My answer addresses OP's original question: what happens if we move file ? Answer is symlink stops working and doesn't follow the file. Glenn is correct that we can move file back and symlink will start working again, but that answer looks at this from different angle. So the answers are not the opposite of each other. I'll update my answer a little bit to clarify that

[Aurelius]

So symlinks point to filenames and not inodes?

[Sergiy Kolodyazhnyy]

@Aurelis yes, exactly, symlinks point to a filename, and hard links point to the same inode.