hard link

[Shivkumar]

Hi,

I understand the use and signifincance of soft link which is created using "$ln -s" command.

But can't undertsand why we need to create hard link ?

Thanks,
Shiv

[James R. Ferguson · Accepted solution]

Hi Shiv:

Hard links provide alternative names by which to access an object (file), just as symbolic (soft) links do.

Hard links, however, point directly to their reference (e.g. file) whereas symbolic (soft) links constitute a name (path) that must be followed to eventually find the object of reference.

As such, then, hard links are faster than soft links.

A disadvantage of a hard link, however, is that it cannot point across filesystems whereas a symbolic (soft) link can. Remember that hard linked files all share a common inode number as exposed by 'ls -il'. Inode numbers are *only* unique within a filesystem. That is, inode #101 can exist in multiple filesystems (mountpoints) but point to wholly different files (or directories). THus, hard links cannot point across filesystems.

Regards!

...JRF...

[A. Clay Stephenson]

and hard links are the traditional UNIX links. They have always been a part of UNIX from its original inception --- unlike symbolic links which came along later to solve the problem of creating links which could span filesystems. hard links are simply multiple directory entries which share a common inode and you are much more familiar with them than you know. For examle the "." and ".." directory names are hard links.

[A. Clay Stephenson]

and hard links are the traditional UNIX links. They have always been a part of UNIX from its original inception --- unlike symbolic links which came along later to solve the problem of creating links which could span filesystems. hard links are simply multiple directory entries which share a common inode and you are much more familiar with them than you know. For example the "." and ".." directory names are hard links.

[Shivkumar]

What are the other files or directories which are the examples of hard links ?

Regards,
Shiv

[A. Clay Stephenson]

You need to learn to start asking the box itself questions like that:

Look for any regular files that have more than 1 link or directories that have more than 2 (all directories will have at least its own name plus ".").

find . -type f -links +1 # regular files with more than 1 link

find . -type d -links +2 # directories with more than 2 links

[Shivkumar]

I apologize with gurus for asking simple questions. Unfortunately, i have very primitive knowledgebase in Unix. I worked for many years on other flavors Unix though. But it seems i have learned and used few commands repeatedly for many years.
I never got opportunity to work in the team of unix sys admins.

I am grateful to gurus and other experts who are sharing their knowledge.


Regards,
Shiv

[inventsekar_1]

Hi Shiv,

From the ln man pages:
----------------------------------------------------------------------
Hard links are created with the same ownerships and permissions as the
file or directory to which they are linked. If ownership or
permissions are changed on a link or file, the same changes appear on
corresponding hard links. The ln command does not permit hard links
to a directory.

Symbolic links are created with the ownership of the creator and the
permissions are of the creator's current umask. Once created, the
symbolic link ownership and permissions will not change, since the
mode and ownership of the symbolic link is ignored by the system.
----------------------------------------------------------------------

[inventsekar_1]

Hi shiv, no problem. your interest to learn is interesting.

The idea is commands can have different names(with the help of alias command). in the same way to give different names to files, they found link(ln) command.

but there are 2 limitations with hard links:
1. hard links cannot cross file systems.
2. hard links cannot link directories.

to make it possible, they found soft links.


wikipedia:
http://en.wikipedia.org/wiki/Ln_%28Unix%29

[James R. Ferguson]

Hi Shiv:

One of the most dramatic examples of hard linked files on HP-UX can be found with the LVM binaries.

For instance, at the shell prompt if you do:

# ls -il /sbin/v*

...you will see that many of the LVM commands share a common binary. At runtime, the *name* of the invoked command can be examined by the binary code to determine what function to perform.

Regards!

...JRF...

[James R. Ferguson]

Hi (again) Shiv:

As a further exercise for you, note the inode number from the output of:

# ls -il /sbin/vgdisplay

You will see something like:

3641 -r-sr-xr-x 31 root sys ...

On one of my systems, that means that inode #3641 belongs to '/sbin/vgdisplay', and there are thirty-one (31) hard links represented by this inode.

Now, using that number (nnnn) as the argument to '-inum' as:

# find /sbin -xdev -inum nnnn

...you should find the thirty-one variations of this binary.

To reinforce (again) that an inode value is only unique within a filesystem, I added the '-xdev' option to the 'find' arguments to prevent traversing mountpoints.

Regards!

...JRF...

[A. Clay Stephenson]

--- and now for the rest of the story about an executable file having multiple links to a common inode, my favorite example is "sh".
Do an "ls -i /usr/bin/sh /usr/bin/rsh" and you will find that both of these point to a common inode --- they are thus hard-linked.
Now ask yourself, how does this executable file know how to behave as either the normal shell (sh) or the restricted shell (rsh)? --- and remember, there is but one actual executable file. If you do a cksum of /usr/bin/sh and /usr/bin/rsh, you will get exactly the same result.

Understanding how this occurs lies at the heart of every executable spawned by the system. Every program has a main that looks like this:

int main(int argc; char *argv[])

argc => the number of arguments passed on the command line; always at least 1 because argv[0] contains the name of the executable.
argv[] is an array of strings that are the arguments.

So the shell program tests to see if argv[0] is "sh" or "rsh" and thus determines its behavior.

Additional Note for more interested students: There is actually a 3rd argument passed to the newly exec()'ed process and that is char **envp; This is a NULL terminated array of pointers containing the environment variables.

------------------------------------

Little gems of knowledge like this are why I think every UNIX admin should at least know some C or C++ because it leads to a much better grasp of how things work (and why they might not be working).

[Shivkumar]

Hi Clay and James,

In the below output:

# ls -il /sbin/vgdisplay

You will see something like:

3641 -r-sr-xr-x 31 root sys ...


If there are so many (31 in this case) files (binary) are pointing towards the same inode then does it mean that hard link concept was designed to accomodate large number of files in superblock ? May be superblock has some limitaton on storing the inode numbers ??

warm regards,
Shiv

[James R. Ferguson]

Hi (again) Shiv:

Filenames point to inodes in the Unix filesystem. The inode holds the metadata associated with the file that points to it. That is, the inode constains things like the file's size, modification time, access time, owner (uid), permissions, etc. Look at the manpages for 'stat(2)' since this describes the system call by which these data are retrieved.

Given that a file*name* points to an inode, the *name* really can be said to be the hard link. The number times different file (names) point to the same inode is maintained as the link count, 'st_nlink'.

Further, from the 'stat(2)' manpages we can see that the link count is an unsigned short integer, so we can have counts up to 65,535 stored!

When the link count is zero, a file is deleted, *unless* it is open by a process. Indeed, it is a common practice to create (open) a temporary file in a program and immediately 'unlink(2)' it. This means that only the owning process can access the file. At process termination, the file and any allocated space vanish. The downside
is that it is more difficult to find who or what is consuming space in a filesystem when something goes wrong.

Regards!

...JRF...