On Tue, 27 Jul 1999, Andy Goth wrote:
> I was about to make that statement earlier, but I then thought it wasn't
> tre since everything that has been said indicated that hard links point
> to a single file and when all hard links die the file does as well (and
> that kinda invalidated what I thought). It's a good thing this isn't
> the case! It's waaay too complicated and unwieldly. Imagine making a
> hard link and changing your mind about it... if this was true, I
> couldn't delete it! The truth is much better. Yeah, that is a good
> idea about deletion protection. If I want to make sure that some data
> cannot be deleted, I can keep a hard link.
I think that you misunderstand.
A hard link is the way that you access a file. BUT, there is only one
file.
Suppose that we have a file named... well, lets create a file:
$ echo put this in a file > hardlink_1
$
We have created a file the "quick" way, and we gave it the name
hardlink_1.
And then we "cat" the file, which shows what is in the file.
$ cat hardlink_1
put this in a file
$
Hardlink_1 is a text file which has the contents, "put this in a file".
OK, lets say it a different way. The echo command sends (we say it
re-directs) "put this in a file" into the contents of a file named
hardlink_1. The ">" character is the nifty command that does this
redirection.
Lets look at the long display of this file:
$ ls -l
total 2
-rw-rw-r-- 1 rtm 465 19 Jul 27 02:09 hardlink_1
$
OK, notice that it has a file size of 19 (just before the date).
Count the characters in the "string" of characters:
123456789012345678
put this in a file
18. One extra byte to store this string gives us the 19.
Now we will add another hard link:
$ ln hardlink_1 hardlink_2
$
...and if we look at our directory again:
$ ls -l
total 4
-rw-rw-r-- 2 rtm 465 19 Jul 27 02:09 hardlink_1
-rw-rw-r-- 2 rtm 465 19 Jul 27 02:09 hardlink_2
$
Both filenames point to the same file. We can display the contents of
both files:
$ cat *
put this in a file
put this in a file
$
Well, actually, we displayed the contents of ONE file twice. Once using
each filename. The * is a wildcard that matches all filenames in the
directory.
OK, now for the test.
We are going to redirect "nothing" to the first hardlink.
$ > hardlink_1
$
We have replaced the contents of hardlink_1 with "nothing". Since there is
nothing in front of the ">", nothing is put into the file, replacing
whatever had been there. Notice that we don't even need the echo command
to do this.
And, ls -l tells the story:
$ ls -l
total 0
-rw-rw-r-- 2 rtm 465 0 Jul 27 02:22 hardlink_1
-rw-rw-r-- 2 rtm 465 0 Jul 27 02:22 hardlink_2
$
For further proof, try to cat the contents of the two files (or more
accurately, the contents of our ONE file twice):
$ cat *
$
Nothing there.
Soooooo, a second hard link doesn't "protect" the contents of a file. It
only offers another way to access the contents of a file.
If we use either hard link to change that file, then the contents are
changed. Period.
Now, lets create a soft link and put something back into the file:
$ ln -s hardlink_1 softlink_1
$
The -s "switch" to the link command ln makes this a symbolic, or "soft"
link, instead of a hard link.
$ ls -l
total 2
-rw-rw-r-- 2 rtm 465 0 Jul 27 02:22 hardlink_1
-rw-rw-r-- 2 rtm 465 0 Jul 27 02:22 hardlink_2
lrwxrwxrwx 1 rtm 465 10 Jul 27 02:35 softlink_1 -> hardlink_1
Whoa! Notice that our soft link is created with WORLD WRITE permissions
(the 3rd "w" in the group of "rwx's" in the line above). Doesn't matter,
the symlink REALLY inherits the permissions of whatever it points to.
Also notice that the symlink has 10 bytes. Why is that?
Now we will put something into the file that the symlink points to:
$ echo another string > softlink_1
$
So, what happens if we cat the contents of all the files in the directory?
$ cat *
another string
another string
another string
$
$ ls -l
total 6
-rw-rw-r-- 2 rtm 465 15 Jul 27 02:35 hardlink_1
-rw-rw-r-- 2 rtm 465 15 Jul 27 02:35 hardlink_2
lrwxrwxrwx 1 rtm 465 10 Jul 27 02:35 softlink_1 -> hardlink_1
$
All of our files now contain 15 bytes-- 14 for the string, plus one. Well,
EXCEPT for the symlink. It still contains 10 bytes. That is because it is
just a pointer to another filename (whether that filename exists or not).
If we remove the first hard link, see what happens:
$
$ rm hardlink_1
$
$ ls -l
total 4
-rw-rw-r-- 1 rtm 465 15 Jul 27 02:35 hardlink_2
lrwxrwxrwx 1 rtm 465 10 Jul 27 02:35 softlink_1 -> hardlink_1
$
$ cat *
another string
cat: cannot open softlink_1: No such file or directory
$
Since our symlink points to a non-existant filename, we cannot display
contents. BUT, the contents still exist under a different filename.
BUT-- the symlink still points to that filename. If we create that file
anew:
$ echo some other NEW stuff in our file > hardlink_1
$
$ cat *
some other NEW stuff in our file
another string
some other NEW stuff in our file
$
Neat stuff, huh? This is Unix.
best wishes,
richard myers
