> > 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.
Remember? I was showing the cause of my misundestanding. I was
confused that there were *files* and separate *hard links* to those
*files*. I do understand now. Filenames are hard links to the data.
Making several hard links to data makes more filenames that point to the
same data.
> 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.
I know. >> is good for appending, too.
> 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.
The extra byte... a character to signal the end-of-file?
> 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.
It protects it from *deletion*, which is what I was talking about. Of
course, since deletion is only one way to wreck a file, it's not that
important.
> If we use either hard link to change that file, then the contents are
> changed. Period.
I understand already! I guess I didn't explain myself very well.
> 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.
I know. I hope all the other replies aren't extra attempts to make me
understand, because I alrady do.
