In this video, I'll tell you about links.
A link is a pointer to a file in a different location.
And you can compare it to shortcuts on other operating systems.
Links can be useful to make the same file available on multiple locations.
And Linux uses hard links as well as symbolic links,
which are sometimes also referred to as soft links.
You can create hard links with ln and symbolic links with ln minus s.
All right, let me explain what links are all about.
It all starts with blocks.
That is how physically your files are stored.
Now, in order to access these blocks, your files are using an inode.
And the inode is an essential component in Linux file system administration.
It contains all the properties of your files.
And every file has exactly one inode.
So from the inode, you can get to the blocks.
But how do you get to the inode?
Well, that is by using a name.
And the nice thing about it is that you can have multiple names for the same inode.
And that is, in fact, what a hard link is all about.
A hard link is a second name that is pointing to the same inode.
Now, in order to create these names, they are stored in the directory table.
This directory table is created on all file systems.
And for that reason, hard links must be on the same device.
And another thing to be aware of with hard links is that you cannot do directories.
In order to add some flexibility to it, there's a second layer of links.
In this case, you don't point to an inode, but you point to a name.
And that is a symlink.
So that's another name.
This is known as the symbolic link.
Also sometimes referred to as a soft link.
Now, symbolic links are pointing to another name.
Interesting to understand what will happen if this other name disappears
because the original file was removed.
Well, then it's very simple.
The symbolic link will become invalid.
You still see it, but it points to nothing.
And for that reason, it won't work anymore.
Before showing you how it works on Linux,
I want to show you how I'm using hard links on my MacBook.
So what's going on?
Here we are in my GitHub directory.
In my GitHub directory, I have several subdirectories
where every subdirectory corresponds to a specific course that I'm using.
And it happens to be that in some courses, I need the exact same file,
like the kubesetup script.
Let me do a find.-name kubesetup.sh.
And there you can see that this kubesetup script exists
in no less than six different directories.
This is an important script that I'm using in different courses that I'm teaching.
And the thing about this script is that I often need to change it.
Now, I've been thinking about it.
How am I going to make sure that if I change it at one location,
it is going to be changed at all other locations as well?
Well, here the perfect solution is the hard link.
All of these files are hard links.
And because they are all hard links,
it doesn't matter which one I'm going to change.
Changing one will change all of them.
It's just six different files pointing to the exact same script.
And that is a very convenient way,
because the alternative way would be to change one of them
and copy it to all over.
Well, that is so confusing.
So hard links are pretty convenient here.
Now, let's get to Linux so that I can show you how to work with them.
All right, so I am going to do what?
I'm going to work with an example file.
And let me use...
No, not touch.
Let me just copy etc hosts to here.
And I'm using ls minus i on etc hosts to ./.hosts.
Minus i option is showing the inode number.
And what I want you to understand first
is that even if the contents of these files is the same for now,
it's different inodes.
So if I change one of the files,
the change is not applied to the other file.
Now I'm going to make a hard link of my hosts file,
and I'm going to continue to work on that from the current directory.
So let's call it hard.
Creating a hard link is like creating a copy.
You start with the source, and then you enter the destination.
And then if I use ls minus il on hosts and hard,
then what do we see?
We see they have the same inode number.
So they are just two pointers to the same data,
which means that if I'm going to add something to either of them,
and using my ls minus il again,
as you can see, the size of both files has grown.
And that is what hard links are doing.
Now if I would create a symbolic link,
then ln minus s is what I'm using.
So I'm calling it hard, and let's call it soft.
Symbolic links sometimes are also called soft links.
When I'm using ls minus il again on hard and on hosts and on soft,
then we can see that soft looks a bit different.
There's an arrow behind soft that is pointing to the name of the destination file.
Notice that what I've done here is not really best practice.
If you want to create symbolic links in the most flexible way,
you should always refer to an absolute path name.
That is because you might want to copy over your symbolic link.
And if I'm going to copy this symbolic link,
well, the symbolic link only knows that it needs to point to a file with the name hard.
And if I copy it over, it will become invalid
because the symbolic link doesn't know anything but the four characters of H-A-R-D.
So make it a symbolic link to an absolute path name to make sure that it survives a copy.
We also see that there are no permissions on the symbolic link
because they are managed on the destination file.
And the symbolic link has obtained a different inode number.
You know what?
Let's move this soft file to the tmp directory and let's see what's happening.
So ls minus l on tmp soft.
Oh, that's a typo.
It's showing what?
Well, this is what an invalid symbolic link is looking like.
I copied it over.
The symbolic link is still looking for a file with the name hard,
but that file doesn't exist.
So in order to fix it, I better remove the file that I copied over,
and I better recreate it in a better way.
So let's create it again using ln minus s slash root slash hard,
and I'm calling it soft.
And then ls minus il on soft is showing that we have an absolute path name that it refers to.
So when I move it to the tmp directory or wherever I want to move it to,
then it should still be valid after the move.
As you can see, this works.
Now, you might be wondering, interesting, but how do I use it?
Well, I would say use hard links if you want to refer to a file.
Symbolic links are required if you want to refer to a file that is on a different file system.
So mount it in a different directory, or if you want to refer to a directory
because you can't hard link a directory.
Let me show you.
ln slash etc to config.
Hard link not allowed for a directory, so make it an ln minus s.
And there you can see that it is working.
So ls minus il.
As you can see, the config directory is pointing to etc.
Now, I want to show you one more thing about all of this,
and that is how Linux is using it itself.
Look at this.
We have bin pointing to userbin, and likewise lib, lib64, and sbin are doing the same.
And there's a reason for it.
The reason is that in the old file system hierarchy standard specification,
bin and lib and lib64 and sbin were directories in the root file system.
And there was also a userbin and a user sbin and a userlib and a userlib64.
Now, at some point, Linux Foundation decided that that doesn't make sense.
So now everything is in slash userbin, slash userlib, etc.
But what would happen if you have a script that has a hard reference to the bin directory?
Well, I can tell you that script would fail, and that is why we have the symbolic link.
So if you have a script that refers to slash bin slash passwd,
well, thanks to the symbolic link, it will really read userbin passwd,
and your script isn't broken.
It's still working.
And that's how links are used as an important part of the Linux operating system.