[meant to be read after you read out sundialsvcs post above:]
You can make symlinks to directories, but you can't make hard links to them. Each directory has hard links --- its listing in its parent directory, its . entry, and the .. entry in each of its subdirectories --- but to impose order on the filesystem, no other hard links to directories are allowed. Consequently, the number of files in a directory is equal to the number of hard links to that directory minus two (you subtract the directory's name and the . link).
if you are still not clear:
To begin, let's review the differences between the two types of links. A symbolic link can be thought of as a "pointer", similar to a shortcut on a Windows system, that records another file or directory's location (relative or absolute). Symbolic links are like a trail of breadcrumbs leading to a new system location when files are not stored in their usual place. For example, if you ran out of space in /var and wanted to move all your messages files to /opt, then you might leave a symbolic link pointing from /var/adm to /opt/adm (i.e., /var/adm ? /opt/adm) indicating to anyone using the system that the files have been moved. A good systems administrator will always make changes such as this obvious so that no one working on the system has to work very hard determining where the files in question have been moved.
Symbolic links also provide a quick way to access a directory. For example, I might create a symbolic link called "logs" in my home directory pointing to /opt/apps/apache/logs so that I can switch to that directory with fewer keystrokes, regardless which shell I am using (aliases can be defined in some but not all shells).
A hard link also references an existing file that is, in all ways save its location in the file system, identical to the original file. It employs the same inode to keep track of the file's descriptive information and refers to the same disk space. I prefer hard links for two reasons: 1) they occupy less system resources by sharing both disk space and inode, and 2) they require fewer disk accesses (a symbolic link requires an extra read to get the name of the file about to be read).
Hard links are often used to make "copies" of files without having to allocate additional disk space and without concern that the "copy" and the original file will get out of synch. Hard links also provide additional names for executables. In fact, many system commands are hard linked. On Solaris systems, /usr/bin/adb is the same file as /usr/bin/ps. Hard linking gives an executable the opportunity to invoke a different character depending on how it is called, while still sharing a good deal of common code.
Because hard links share inodes with each other, they must exist in the same file system. Inodes are part of a file system, defined when a file system is created. This is not true of symbolic links, which can refer to a file anywhere on a system since they only store the pathname to the referenced file.
So, when can't you use a hard link? The first answer is clear from what I said above; when you are referring to a file or directory that is part of another file system, you cannot use a hard link. However, you can use a symbolic link or copy the file to the new location, which risks the files becoming out of synchronization with each other. The more surprising answer, though it makes complete sense when you think it through, is that you cannot use a hard link when the file that you're linking to is a symbolic link -- unless that symbolic link contains an absolute (not a relative) path to the file that it links to or is in the same directory as the link being created. Why? A hard link is a duplicate of a file, another reference in the file system; hard linking a symbolic link will, therefore, create another symbolic link and, if the relative location is not valid from the new link's location, then the link will be "dangling" (i.e., pointing to something which doesn't exist).
Let's take a simple example. You create a hard link to point to /usr/java/bin/java so that you can also refer to it as "myjavaapp":
% ln /usr/java/bin/java myjavaapp
What you didn't realize was /usr/java/bin/java was a symbolic link pointing to .java_wrapper. Your link will also point to .java_wrapper. Unless you just happen to have this file in your directory too (not very likely!), myjavaapp isn't going to work as you expected.
source:
http://www-rohan.sdsu.edu/doc/debian/ch-advanced.html
http://www.itworld.com/nl/unix_sys_a.../pf_index.html
not so much here... but if I'm at work and I'm in a meeting describing my mounts.
