Hard links only work for files, not directories.

remove symbolic file link

del <link-name>

remove symbolic directory link

rmdir <link-name>

Can I create a symbolic link pointing an online file? (Like... an web located file, for example.) If the answer is yes, how?

Short answer, yes, you could create it, since the symbolic link creation process does not evaluate what is stored in the link for validity as a file reference, just that it is a string of >0 length. Thus you could store in a symbolic link a value like ftp:// or http:// www.mywebsite.com/myfile.txt (which I presume is the type of 'web located' reference you're referring to) and mklink won't complain.

When you do a file operation on a path that link is part of, however, that operation will most likely fail because no drive mount or network share will match the "http:" portion of the reference. It might succeed if some 3rd party kernel mode driver that extends the path parsing process is installed, but I don't know of any that do so. To make such a driver so that it would be transparent to current applications would require doing the equivalent of SetProcAddress on multiple kernel and user mode APIs, many of which are not exports from their app or library modules to begin with, to replace all the code where paths are checked for validity. I suspect rather than doing this so multi-letter drive designators could be recognized, MS opted to implement the directory form of volume mounts for NTFS as the easier alternative.

To setup a symbolic or hard link to another computer over the internet that has a chance of being useful you have to establish and reference a VPN connection through the share name associated with it, be it a drive letter or UNC type name, and setup LAN Manager so it would report that connection as equivalent to a local file. Whether that would also require an add-on I'm not sure of, but such an add-on would be nominally easier to write.

Can I create a symbolic link pointing an online file? (Like... an web located file, for example.) If the answer is yes, how?

Hard links (/H) and junctions (/J) do not require SeCreateSymbolicLink, so can be run without elevation.

pls enter the folder %systemroot%/system32, find cmd.exe, then right click and choose "run as an administrator" (sth. like that), mklink will run well in this cmd window.

Creation of symbolic links requires the SeCreateSymbolicLinkPrivilege (“Create symbolic links”), which is granted only to administrators by default (but you can change that using security policy). The stated reason for this requirement is: “This user right should only be assigned to trusted users. Symbolic links (symlinks) can expose security vulnerabilities in applications that aren't designed to handle symbolic links.” (See secpol.msc, or http://technet.microsoft.com/en-us/library/cc766301(WS.10).aspx)

I was testing an application which checked it's home running directory (it seems anyway) to know wether it's running; copying it to another directory worked in making the application start another process.

I though it would be clever to make a link to "sub" to "." (which actually works perfectly fine; and the application ran multiple times too), however when browsing in Explorer, for some reason it keeps expanding the infinite loop of symlinks! I even tried isolating the symlink in real directory; it still expanded it on it's own for unknown reasons.

So my guess is since it's so easy for someone to accidently do this, they wanted to protect "normal" users from using this - specially if using older applications unaware of the possibility of infinite loops...

I am trying to run it in a directory where even a non-elevated user is allowed to write.

No idea why it required admin privileges but it might be to do with the confusion that making a hard link could cause. It doesn't seem that illogical (do you really want users making hard links everywhere which could cause backup loops, etc?). MS has always been a little shy over this feature, but I think I agree that if you have full control over a folder you should be able to mklink in that folder to another folder you also have access to.

At a very minimum, MS should explain this feature and why it's privileged.