Reputation: 23567

Symlink broken right after creation

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?

Upvotes: 59

Answers (5)

Pavel Pančocha

Reputation: 71

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 :)

Upvotes: 0

rici

Reputation: 241741

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:

create a directory entry inside your bin subdirectory with name torbrowser.
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.

Upvotes: 109

ozgeneral

Reputation: 6779

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

Upvotes: 0