There are a lot of quite correct answers here, but I don't think anybody really tackled the original misperception. The original question is basically "when I make a symbolic link, it's easy to identify it afterwards. But I can't figure out how to identify a hard link." And yes, the answers basically boil down to "you can't," and more or less explain why, but nobody seems to have acknowledged that, really, it is confusing and strange.
If you're reading all this and you've figured out what's going on, then you're good; you don't need to read my little bit. If you're still confused, then keep going.
The really really short answer is that a hard link isn't really a link at all, not in the way a symbolic link is. It's a new entry in the directory structure that points to the same bunch of bytes that the original directory entry did, and once you've created it, it is just as "real" and legitimate as the first one. Every "normal" file on your drive has at least one hard link; without that, you wouldn't see it in any directory, and would be unable to refer to it or use it. So if you have a file Fred.txt, and you hard link Wilma.txt and Barney.txt to it, all three names (and directory entries) refer to the same file, and they are all equally valid. There isn't any way for the OS to tell that one of the entries was created when you hit "save" in your text editor, and the others were made with the ln command.
The OS does have to keep track of how many different entries are pointing to the same file, though. If you delete Wilma.txt, no surprise that you don't free up any space on your drive. But if you delete Fred.txt (the "original" file), you still won't free up any space on your drive, because the data on the drive that was known as Fred.txt is still also Barney.txt. Only when you delete all of the directory entries will the OS de-allocate the space that the data itself was occupying.
If Barney.txt had been a symbolic link, then deleting Fred.txt would have de-allocated the space, and Barney.txt would now be a broken link. Also, if you move or rename a file that has a symbolic link pointing at it, you'll break the link. But you can move or rename a hard-linked file all you want without breaking the other directory entries that point to that file/data, because all of them are directory entries that refer to the same block of data on the drive (by using the inode number of that data).
[It's two years later, and that last bit confused me for a minute, so I think I'll clarify. If you command mv ./Wilma.txt ../elsewhere/Betty.txt, it seems like you're moving the file, but in fact, you are not. What you're really doing is removing a line item from the directory list of your current directory, the one that says "the name Wilma.txt is associated with the data that can be found by using inode 1234567," and adding a new line item to the directory list of directory ../elsewhere that says "the name Betty.txt is associated with the data that can be found via inode 1234567". This is why you can "move" a 2 gigabyte file as quickly as a 2 kilobyte file, as long as you're moving them to another location on the same drive.]
Because the OS has to keep track of how many different directory entries are pointing to the same chunk of data, you can tell if a particular file has been hard linked to, even though you can't tell for certain if the directory entry that you're looking at is the "original" one or not. One way is the ls command, specifically ls -l (that's a lower-case L after the dash).
To borrow an earlier example....
-rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 f1
The first letter's a dash, so it's not a directory or something else exotic, it's a "regular" ordinary file. But if it were truly ordinary, that number after the rwx-ish part would be 1, as in, "there is one directory entry pointing to this block of data." But it's part of a demonstration of hard links, so instead it says 3.
Note that this can possibly lead to weird and mysterious behavior (if you haven't wrapped your head around hard links, that is). If you open Fred.txt in your text editor and make some changes, will you see the same changes in Wilma.txt and Barney.txt? Maybe. Probably. If your text editor saves the changes by opening the original file and writing the changes to it, then yes, all three names will still be pointing at the same (newly changed) text. But if your text editor creates a new file (Fred-new-temp.txt), writes your changed version to that, then deletes Fred.txt, then renames Fred-new-temp.txt to Fred.txt, Wilma.txt and Barney.txt will still be pointing to the original version, not the new changed version. If you don't understand hard links, this could drive you slightly mad. :) [Okay, I don't actually personally know of any text editors that would do the new-file/rename thing, but I do know of lots of other programs that do exactly that, so stay alert.]
A final note: one of the things that fsck (file system check) checks for is if there are blocks of data on your drive that somehow are no longer referenced by any directory entries. Sometimes something goes wrong, and the only directory entry that points to an inode gets deleted but the drive space itself doesn't get marked as "available." So one of fsck's jobs is to match up all the allocated space with all the directory entries to make sure that there aren't any unreferenced files. If it finds some, it creates new directory entries and puts them in directory lost+found.
ln /foo/bar/ /foo/bar2makes a hardlink whileln -s /foo/bar /foo/bar2makes a symlink, thats what he means?bar2andbarare both hard links, just pointing to the same inode.barandbar2are equally important. One is not a link to the other, they are both links but point to the same inode.lnare no different than regular files.