Symlink broken right after creation

Question

I downloaded the linux Tor Browser package, which is a self-contained folder. I made a symlink to the run script:

$ ln -s torbrowser/start-tor-browser ~/bin/torbrowser

However, the link was broken upon creation. All I did was run that command, nothing else, and it was broken. I did ls and got:

lrwxrwxrwx 1 synful synful 28 Jul 18 21:52 torbrowser -> torbrowser/start-tor-browser

...which is weird because torbrowser/start-tor-browser had 755 permissions. Also, I ran file:

$ file ~/bin/torbrowser
bin/torbrowser: broken symbolic link to `torbrowser/start-tor-browser'

I made a new bash script and a symlink to it to test this, and had no such problems. I'm not sure why it's only happening with start-tor-browser. It's got normal permissions and is just a normal bash script (even according to the file command).

...any ideas?

Potsherd

I always use absolute paths when dealing with symlinks. Almost all my use cases are similiar to yours. :) – Findley

Answer 1

It's important to know that

ln -s SOURCE TARGET

create a symlink called TARGET which is symbolically linked to the string SOURCE. If SOURCE is a relative path (that is, it does not start with /), then it is interpreted relative to the directory that TARGET is in. If it is an absolute path, then it's an absolute path. If it is a string which could not be a path, or includes a non-existing path or file, or is otherwise not a valid path string, no matter. ln -s does not check that SOURCE exists or is even a valid path. You could store almost any shortish string you wanted in the dirent.

So when you do this:

$ ln -s torbrowser/start-tor-browser ~/bin/torbrowser

what you are doing is, roughly:

1. create a directory entry inside your bin subdirectory with name torbrowser.
2. Make that new directory entry a symbolic link (symlink) to the (relative) path torbrowser/start-tor-browser

The new symlink is a circular. ~/bin/torbrowser is linked to ~/bin/torbrowser/start-tor-browser, which means you have to follow the symlink in order to resolve the symlink. If you try to use it, you'll see:

$ cat ~/bin/torbrowser
cat: /home/joshlf13/bin/torbrowser: Too many levels of symbolic links
$

Sometimes -- often, even -- the ability to symlink to a relative path is extremely handy. A common use is getting rid of version numbers:

$ ln -s apps/my_fancy_app_v2.63.1 apps/my_fancy_app

Now, not only can I call my_fancy_app without remembering its version string, I can also move the entire folder elsewhere, without breaking the symlink:

$ mv apps /usr/local/apps

But other times -- as in your example, I think -- you need to symlink to an absolute path.

As for the permissions, symlinks always have permissions lrwxrwxrwx because the actual permissions used by file operations are the permissions on the real file. (You can think of that as meaning that anyone can follow the symlink, but that's not quite true: they'd also need read permissions for any directory they need to follow. More accurately, anyone who can see the symlink can see the name it points to, even if they have no access to the file with that name.

Lianaliane

It's important to put the full path in order not to get a broken link – Begum

Absolute path is what fixed the problem for me, but the problem should have never occurred with a properly ref'd local file either.. – Tilford

Answer 2

It is important that the TARGET you specify in

ln -s TARGET LINK_NAME

is full path of the file/directory. I had this issue, in my case when I cd into target's directory and did

ln -s ./eclipse.ini ~/Desktop/eclipse1 resulted in broken link

But when I did this ln -s $(pwd)/eclipse.ini ~/Desktop/eclipse It worked!

Undermine

Thank you, this is what I really want to know – Torchier

Answer 3

the above usage given for ln:

ln -s SOURCE TARGET

is correct, but confusing when referred to the man page:

ln [OPTION]... [-T] TARGET LINK_NAME (1st form)

as 'TARGET' has different meaning

Arthur

Consistently with cp: cp existing new. Likewise: ln -s existing new – Casque

Answer 4

Note: this can also happen due to permissions eg. if you try

sudo ln -s /home/somesuperuser/commonfile /home/somenormaluser/commonfile

this would not work, while

sudo mv /home/somesuperuser/commonfile /usr/share/commonfile
sudo ln -s /usr/share/commonfile /home/somenormaluser/commonfile
sudo ln -s /usr/share/commonfile /home/somesuperuser/commonfile

does work

Cilla

Answer 5

I also struggled with this, I got lots of time Linux sym link broken after creating, but solution is simple - as mentioned by rici:

If SOURCE is a relative path (that is, it does not start with /), then it is interpreted relative to the directory that TARGET is in.

In other words:

You have this dirs:

- my_directory
-- directory_1
- other_directory
-- *you want your directory_1 link here*

Easiest approach. Got to "other_directory". From there is simple:

ln -s ../my_directory/directory_1 directory_1

Done :)

Marcellusmarcelo