Hard links vs. Soft links

[Roland McGrath]

In article <1084.26d2a42b at desire.wright.edu>, anagram at desire.wright.edu
((For Mongo)) writes:
|>What is the difference between a hard link and a soft link?  Besides the fact
|>that a hard link seems to make a copy of the file, while the soft link just
|>points the OS to the real file.

You have a serious misconception about this.  The way Unix files work is that
each file is described by an i-node, which contains modification times,
permissions, etc., and points to where the data is stored on disk.  Each i-node
on a disk has a unique number.  Thus each file is uniquiely described by its
device number (which says what disk it's on) and its i-node number.

Directories are special files which contain only directory entries.  Directory
entries consist of a name and an i-node number.  Each directory entry which
refers to a given i-node is a hard link to the file that i-node describes.  If
there are multiple hard links to a single file, (which happens when you create
a hard link to an existing file with "ln foo bar"), each link is equivalent.
The first one made is not in any way special; they are all "the real file".

Symbolic (soft) links are a special type of file which contain a path name.
Under most circumstances, when the system encounters a symbolic link, it reads
the path name and uses that instead for whatever operation it was doing.  (The
exceptions are symlink, readlink and lstat, which deal specifically with
creating and inspecting symbolic links.)

|>In broader terms, my question is this: I have a Tektronix 4301 that has the
|>commands ls, ll, lf, lg, and lx, all of which are derivatives or ls.  They
|>are all the same size, and they are all linked together.  When I had a system
|>error and all the links were destroyes, I deleted them all, except ls, and
|>re-linked them using soft links.  I saved about a quarter of a meg of
|>disk-space.

Those were not hard links.  They were copies.  I'm not sure how your system
error made removed the extra links and made new copies of the file with the
same name all by itself.  Sounds more like a human error to me.

|>I have come across some other files that are the same way, and am wondering
|>how much space I can save, compared to how much system performance I will
|>lose.  Can anyone tell me how soft links vs.  hard links will affect system
|>performance.

Hard links will save space and be more efficient.  They are just harder to deal
with, since, although you can find out how many hard links exist to a given
i-node (the link count is the first number in an "ls -l" listing), it is
nontrivial to find out where they all are.

Hard links save space over symlinks because a symlink is another file (though a
small one; its contents are the path name of the file it refers to), including
a directory entry giving the i-node of the symlink, while a hard link is just
the directory entry.  Hard links are more efficient than symlinks because once
the system reads the directory entry for a hard link, it has the i-node number,
which tells it where on the disk to find the file, while after reading the
directory entry for a symlink, the system must then go find its contents on the
disk, and then do name resolution all over again to find the directory entry it
refers to, and then use the i-node number in that directory entry to find the
file on disk (unless, of course, it's a symlink to a symlink, in which case it
has to go through the whole process yet again).

If by "the same way" you mean identical copies, then it's probably a good idea
to remove the extra copies and replace them with links.  Using symlinks will
be easier to deal with, and the wasted space and efficiency is negligible.

If you mean that you have files to which there are multiple hard links, then
the only thing you will gain by replacing the hard links with symlinks is that
you will confuse yourself less.

If you want to know how many links there are to a given file, look at the first
number in an "ls -l" listing.  If you want to know if two files are the same
file, do "ls -i" on them and compare the i-node numbers.
--
	Roland McGrath
	Free Software Foundation, Inc.
roland at ai.mit.edu, uunet!ai.mit.edu!roland