This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: Sym Links: A Question
From: Rob Napier <rnapier@employees.org>
Date: Tue, 30 Mar 1999 14:50:39 -0500
On Mon, Mar 29, 1999 at 07:54:40AM -0500, Statux wrote:
> Here's what's probably a cheesy question:
>
> What's the difference between a soft and a hard link? :)
Say I have a file 'foo' and a symbolic link 'bar' that points to
'foo':
ln -s foo bar
lrwxrwxrwx 1 rnapier 3 Mar 30 14:43 bar -> foo*
-rwxrwxr-x 1 rnapier 73 Mar 26 18:18 foo*
'bar' here is just a pointer to a file named foo. If I read 'bar',
linux looks up 'bar' and see 'go look at foo', which it does. If you
remove foo, bar will still point to some file called 'foo', even
though it doesn't exist. So if I create a new file named 'foo', bar
will still point to it. If I unlink (rm) bar, the link will be
removed, but foo won't be touched.
Notice the "1" in the second column. That's how many hard links are
made to this file. There is a directory entry that points to the
symbolic link bar, and a directory entry that points to the file foo.
foo and bar are really different things, though. One is a link, the
other is a file.
Now, let's make a hard link:
ln foo bar
-rwxrwxr-x 2 rnapier 73 Mar 26 18:18 bar*
-rwxrwxr-x 2 rnapier 73 Mar 26 18:18 foo*
Notice there's no arrows and the number "2". Now bar and foo are
really the same file. They are both hard links, which is why we get
"2" (there are now two directory entries that point to this same
file). One reason we keep track of how many hard links are pointing to
a file is so when we unlink (rm) bar, we know that we can't get rid of
the file yet, because there's still one directory entry pointing to
it.
The point is that directory entries are just pointers to files. Hard
links make two directory entries point to the same file. Symbolic
links make one directory entry point to another one.
In a normal users life, you will generally only use symbolic links.
Hard links are hard to track and can be very confusing. Of course
symbolic links can also be very confusing, but they're too useful not
to use anyway.
=============
Subject: Re: Sym Links: A Question
From: Rob Napier <rnapier@employees.org>
Date: Thu, 1 Apr 1999 10:19:32 -0500
On Thu, Apr 01, 1999 at 01:18:47AM +0000, Cameron Simpson wrote:
> On 31 Mar 1999, in message <19990330145039.D6095@cisco.com>
> Rob Napier <rnapier@employees.org> wrote:
> | > What's the difference between a soft and a hard link? :)
> [... description deleted ...]
> | The point is that directory entries are just pointers to files. Hard
> | links make two directory entries point to the same file. Symbolic
> | links make one directory entry point to another one.
> |
> | In a normal users life, you will generally only use symbolic links.
> | Hard links are hard to track and can be very confusing. Of course
> | symbolic links can also be very confusing, but they're too useful not
> | to use anyway.
>
> Argh. I see this advice everywhere. It Is Bad.
>
> There are times and places for both types of link, but in general symlinks
> are overused.
>
> Hard links provide robustness against forgetting which end of the link
> you're blowing away ("whoops, blew away the real thing - doh!") since
> with a hard link there is no "real thing". They have other advantages
> too.
[... rest deleted for space ...]
All I can say is that in my years of sysadmin and tools development,
I've only once or twice come across a good reason for a hard link. All
of your points regarding soft links are true: they're slower, they're
more prone to nastiness on recursion, they're easy to break. Despite
that, they provide way too much documentation to be easily replaced
with a hard link. A good example is the /etc/X11/X link. I'd really
hate for that to be a hard link. I'd hate to have to use a 'find
-inum' just to figure out what X server you're running, particularly on
a production machine (and especially on a very large production
machine). The incredibly slight performance boost on startup just
isn't worth the hassle later, when you find out that you were really
running /usr/local/etc/vmware/XFCom_SVGA (and have to do a find over
the entire machine to figure this out because it isn't in the normal X
server location).
And for directory linking, you definitely don't want to get into the
hard linking world (which is why most OSes won't even let you do it
unless you're root). It's hard enough to figure out what ".." should
be is when you're using symlinks!
So my advice still stands. Read what Cameron posted so you can
understand the tradeoffs of using symbolic links, but unless you
really have a good reason, I'd stay away from hard links. They're used
in some places in the system (like linking together executables that
are implemented with the same binary [rsh, rexec, rlogin are all the
same binary on some systems for instance]), and the people who chose
to do it that way were quite correct, but most users aren't developing
programs that use $0 to determine their behavior. Most users are just
creating a few links for convenience, and there I still say symlinks
are the way to go.
=========
Subject: Re: Sym Links: A Question
From: Steve Borho <sborho@ststech.com>
Date: Thu, 1 Apr 1999 10:04:08 -0600
I just have to throw this in there. The coolest use I've ever seen for the
use for hard links was documented in the kernel-list FAQ for a method of
building kernel patches. Basically, you un-tar the original source into a
directory, then use cp -i to create a copy of the entire source tree which is
in fact made up entirely of hard-links to the original source. This takes up
very little HD space (one directory entry per hard link) and running diff to
create patches is fast because you are diff'ing the same file against itself.
And when you're done making the patch, the hard-link tree can be deleted in a
hurry.
I'm fuzzy on how this part worked, but somehow you can set it up so that if
you modify a file in the new hard-link tree, it will make the kernel
copy-on-write and create a new file so you never modify the original source.