Symlink broken right after creation

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!

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

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.