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
The dir1/ln2dir21 symbolic link you created is relative to dir1.
The correct command would be:
ln -s ../dir2/dir21 dir1/ln2dir21
As another test, if you go to dir1 and create dir2/dir21 you will see that the red indicator will go away:
cd dir1
mkdir -p dir2/dir21
ll
You will see ln2dir21 -> dir2/dir21/ in normal color (no red error color).
Best Answer
See https://stackoverflow.com/questions/10456784/behavior-of-cd-bash-on-symbolic-links.
You can use 'cd -P' to go to the "real" parent directory. See the first comment on the top answer on how to make this the default behavior.