Why we can't create hard links for directories in linux?
 

In linux, why we can not create hard links to directories?
Hard links to only files are provided?
Can anyone help?

ln -s TARGET DIRECTORY

Hard-links of all types are available. Symbolic links, though, are more useful in many cases.

Thanks Sundialsvcs for your reply. But my question still remains unanswered. My question was "Why we can not create hard links to directories in unix?"

directory contains other entries
 

suppose that you have created a hard link to a directory, the files inside the directory still are the same normal files accessed from different locations. now, if you try to remove any one of the directory using 'rm -rf' command, the files will be removed before the directory itself is removed. obviously, this is not what we want... right?


i guess it could be the reason...

No, the targeted directories will not be removed (this has been my experience on Redhat boxes) -- only the links are removed.

is it possible to create hard links to directories?
 

i tried to create hard link to directory in my fc4 box, but it says "Operation not permitted". so, how did u do this in your redhat system...

from the GNU ln manual it seems that "you cannot make a hard link to a directory"

then i believe i was right !!

Perhaps our definitions are screwed up (on my end). I use hard links (or perhaps what I thought they were) for apps like WebSphere and Apache whenever I need to map out a partition that is either mounted from remote or it's just in an area on the local drive where there's a good reason to keep it there (outside of the usual locations like /var/www/html or /opt/WebSphere/AppServer/installedApps)... If I'm wrong, please let me know so I don't keep looking stupid :) not so much here... but if I'm at work and I'm in a meeting describing my mounts.

H

hi,

what i believe is that we cannot create hard links to directories. and the reason i think this is not permitted has already been explained in a previous reply. i couldn't get exactly what you meant, but hope that you are using sym links and not hard links...

[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