Breaking down the command:

The 'ln' command creates a couple of different types of links to files. Plain 'ln /some/file /other/link' makes hard link, i.e. a new directory entry /other/link which refers to the exact same file as /some/file. In Unix/Linux systems each entry in a directory simply gives a name to a file: a file can have many different names, or even none at all. There is no way after creating a hard link to tell which is the original name of the file and which was created second. If you delete one filename the other will still exist.

There are some limitations though: hard links to a file must all be on the same device as the file (so you cannot link to a file on a memory card), and you cannot create a hard link to a directory: the file-system could support that, indeed the latest Apple operating system does, but it would make it possible to create infinite loops in the filesystem which would cause problems.

The '-s' option to 'ln' makes it create a 'symbolic link'. This is a bit like a windows 'shortcut': it is a special type of file which contains a path to another file. When you access the link then it is usually just like accessing the file directly, but programs which want to can detect when they are using a symbolic link: they aren't symmetric the way hard links are. If you delete the original file then the link will become broken. If you want you can create a symbolic link to anything which has a path even on another device. You can also create symbolic links which point to directories, and that lets you create loops in the filesystem.

Programs which walk over a Linux filesystem are supposed to be intelligent about symbolic links and not end up going round in circles forever. There are several ways to do this, but the simplest is just never to follow a symbolic link: when you are walking the entire filesystem you'll find everything anyway.

However, it looks like I gave you bad advice over that shortcut. There is a bug report about this: https://bugs.maemo.org/show_bug.cgi?id=1760

Bascially it seems that there is a process called 'metalayer-crawler' which walks over the filesystem looking for media files and indeexing them. Unfortunately this process follows symlinks, so if you create a link which causes a loop in the filesystem it just goes round in circles. The result is your media never gets indexed, and your battery gets drained.

The bug report I linked to says it is fixed, but it doesn't look fixed to me.