keith smith wrote:
> I'm needing to share some files between two hosting accounts and am
> looking at creating a few symbolic links.
> 
> In reading the man page for ln it says it creates a hard link by default
> or I can use --symbolic to create a symbolic link. 
> 
> What is the difference between a hard link and a symbolic link and why
> would I want to use one over the other?

I've often thought that 'hard link' is a horrible name for what it is.
It only makes sense if you know a bit about the internals of file
systems.  At a conceptual level, it's not a link at all... it's just
another name for the same chunk of data.  That's not say that I know of
a better name.  "call_this_file_by_another_name" just doesn't have the
proper Unix ring to it :-)

Anyway, here's an example:

Say I have a file that contains the text "Hello World!".  I save it to
disk as a file called 'hello.txt'.  This is what the file listing looks
like:

$ ls -li hello.txt
4801099 -rw-rw-r-- 1 kurt users 13 2007-11-09 17:59 hello.txt

Note two things.  The first is the large number up front.  That's the
"inode" number.  You could think of that as the internal name for the
file (whereas 'hello.txt' is a "user-friendly" name).  If, as a
programmer, you are more comfortable with the idea of pointers, then you
can accurately think of an inode as a pointer to a chunk of data.

The second thing to notice is the '1' just after the permissions and
just before 'kurt'.  For all practical purposes, that's the number of
user-friendly names that exist for the data that inode 4801099 points to.

So let's create another name for the same file using 'ln'

$ ln hello.txt world.txt
$ ls -l hello.txt world.txt
4801099 -rw-rw-r-- 2 kurt users 13 2007-11-09 17:59 hello.txt
4801099 -rw-rw-r-- 2 kurt users 13 2007-11-09 17:59 world.txt

Notice that the inode (pointer) for the two files are *identical*.
Also, both have '2' for the name count.  Why is that?

It's because we just made 'hello.txt' and 'world.txt' two names for the
exact same file.  They are now 100% identical in every possible way.
Don't think of 'world.txt' as a link to 'hello.txt' because that's not
true.  They are both the exact same, neither is in any way more original
or more real than the other since, well, they are just names!

That's why if you delete 'hello.txt', then nothing at all happens to
'world.txt'.  All you did was delete one of the user-friendly name of
that file.  If you then delete 'world.txt'... well, that deletes the
file because now you don't have any way of referencing the data.

Symbolic links are just simple little aliases pointing to a real file.
Let's say that our 'world.txt' was a symbolic link rather than a "hard
link":

$ ln -s hello.txt world.txt
$ ls -l hello.txt world.txt
4801099 -rw-rw-r-- 1 kurt users 13 2007-11-09 17:59 hello.txt
 114725 lrwxrwxrwx 1 kurt users  9 2007-11-09 18:09 world.txt -> hello.txt

Notice that the inode is different, the file size is different, the size
is different... even the date is different.  That's because 'world.txt'
is its own file.  It just contains the path to the original.

That's why it's 9 bytes, btw.  That's the size of the path to
'hello.txt' (9 chars).  Let's make the path an absolute one:

$ ln -s /home/kurt/hello.txt world.txt
$ ls -l hello.txt world.txt
4801099 -rw-rw-r-- 1 kurt users 13 2007-11-09 17:59 hello.txt
 114725 lrwxrwxrwx 1 kurt users 20 2007-11-09 18:12 world.txt ->
/home/kurt/hello.txt

Note that the size of the file is now 20 bytes... which is (not
coincidentally) the number of characters in the full path.

Since symbolic links just contain a path, that means that they can point
to files on a different filesystem.  Hard links, since they are just
another name for a file, couldn't possibly exist on a separate filesystem.

One more esoteric point: You cannot make a hard link to a directory but
you can make a symbolic link.  The reasons why you cannot are deep and
mysterious... okay, not really.  Allowing multiple names for the same
directory could trivially easily allow recursive directory listings
which would totally hose a filesystem.  So they are simply not allowed.

(Slight digression: Mac OS X 10.5 now allows hard links to directories
with their HFS+ filesystem.  They use it extensively in their Time
Machine backup system.  It allows them to make multiple backup copies
without requiring them to create potentially thousands of directories
(and using up all of those precious inodes).  I really really wish we
had that with jfs, ext3, or some other Linux-available filesystem).