ISO27001:2013
Certified Supplier

FIND OUT MORE

We're an ISO27001:2013 Certified Supplier

blog-post-featured-image

File links are an integral part of the Linux filesystem, and a good understanding of them is essential if we are to manage our Linux systems effectively. It seems that most people sort of know what they are, but few understand them in detail.

Hard and Soft

There are two types of links, “hard” and “soft” (or “symbolic”). A hard link points to an inode, which in turn describes a filesystem object such as a file or a directory. A long directory listing will show how many hard links each entry has:

The number after the permissions mask is the number of hard links to that inode. For the regular files in the examples above, that’s 1 – the name on the line is the link to the file.

For the acpi directory, though, it’s 3, which implies that there are three names pointing to that entry. One of them is the name on the line, and looking inside the acpi directory tells us what the other two are:

The first additional name is the . directory, which points to itself (acpi), and the second extra name is the .. directory inside events, which points to its parent (acpi). So, the three names that point to the acpi entry are:

We can see from that example that the number of links to most directories will be 2 plus the number of subdirectories within that directory.

Creating Hard Links

We can create additional hard links to regular files with the ln command. It may be easier to remember the syntax of the command by comparing it to the copy (cp) command, which has the format:

Similarly, the syntax for the ln command is:

Here’s a directory with one file:

We can create a new link to the file with ln:

This isn’t two files: it’s two names that point to the same file, and we can see that each entry has two links. If we display the inode numbers that each name points to, it becomes apparent that there is only one file:

Removing a link

The rm command, strictly speaking, doesn’t delete files: rather, it removes a link to a file. Let’s remove one of the links:

The link count has decremented to one, but the file itself is unchanged. If we were to rm mynewlink, the remaining link would be removed, the link count would become zero, and the filesystem would reclaim the space used by the file.

The file itself – the data – would still exist, but be unreferenced by any directory entry. The space that the data occupies would be available for use by another file and, in the fullness of time, would be overwritten. That’s why simply using rm on a file with sensitive data isn’t secure.

Hard Link Restrictions

The filesystem is very particular about hard links to directory names because it would be easy to set up directory loops that are hard to parse. For that reason, it’s difficult to set up additional hard links to a directory:

Hard links to files are only possible within the same disk partition because the hard link is a pointer to the inode, and inode numbers are only unique within a partition:

Symbolic Links

Symbolic links, soft links or symlinks are all names for the same thing. A symlink is a pointer to another filename entry, as opposed to a pointer to the inode (file) itself. We can create a symlink with ln -s:

Here we can clearly see that mysymlink points to a file name, and the leading l in the permissions shows that this is a (symbolic) link. In truth, all directory entries are links, and the symbolic links are distinguished from hard links by that leading l.

We can see that the symlink doesn’t directly reference the file by looking at the inode numbers:

Here, the symlink inode number (37888876) differs from the filename it points to (37861771), showing that the symlink is a file in its own right.

Unlike hard links, a symlink can point to a directory or a file (or directory) on another partition:

Symlinks In Real Life

Most applications will follow symlinks without complaint, so if your application expects its configuration file to be called /usr/lib/myapp/myapp.conf but you want to keep your configuration file under /etc/myapp, we can do this:

Your application will try to open /usr/lib/myapp/myapp.conf, follow the symlink to /etc/myapp/myapp.conf, and open it seamlessly.

There’s a shortcut we can use when creating a symlink that has the same name as the real file (but in a different directory, of course). In the above example, we could do this:

In the ln -s command above, we haven’t specified the name or location of the symlink, so by default it is created in the current directory with the same name as the real file:

Could this Linux Tip Be Improved?

Let us know in the comments below.

Leave a Reply

Your email address will not be published. Required fields are marked *