Ubuntu Server 18.04 – Using symbolic and hard links

How to manage remote IIS on Windows Server 2019

With Linux, we can link files to other files, which gives us quite a bit of flexibility with how we can manage our data. Symbolic and hard links are very similar, but to explain them, you’ll first need to understand the concept of inodes.

An inode is a data object that contains metadata regarding files within your filesystem. Although a full walkthrough of the concept of inodes are beyond the scope of this tutorial, think of an inode as a type of database object, containing metadata for the actual items you’re storing on your disk. Information stored in inodes are details such as the owner of the file, permissions, last modified date, and type (whether it is a directory or a file). But as a refresher, an inode is a data object that contains metadata regarding files within your filesystem. Inodes are represented by an integer number, which you can view with the -i option of the ls command. On my system, I created two files: file1 and file2. These files are inodes 4456458 and 4456459 respectively. You can see this output in the following screenshot where I run the ls -i command. This information will come in handy shortly:

Output of ls -i

There are two types of links in Linux: symbolic links and hard links. This concept is similar in purpose to shortcuts created in graphical user interfaces. Almost all graphical operating systems have a means of creating a shortcut icon that points to another file or application. I’m sure you’ve seen shortcut icons to applications on Windows or macOS systems. Even Linux has this same functionality in most desktop environments that are available. On a Linux server, you typically don’t have a graphical environment, but you can still link files to one another using symbolic or hard links. And while links approach the concept of shortcuts differently, they pretty much serve the same purpose. Basically, a link allows us to reference a file somewhere else on our filesystem.

For a practical example, let’s create a hard link. In my case, I have a couple of files in a test directory, so I can create a link to any of them. To create a link, we’ll use the ln command:

ln file1 file3  

Here, I’m creating a hard link (file3) that is linked to file1. To play around with this, go ahead and create a link to a file on your system. If we use ls again with the -i option, we’ll see something interesting:

Output of ls -i

If you look closely at the output, both file1 and file3 have the same inode number. Essentially, a hard link is a duplicate directory entry, where both entries point to the same data. In this case, we created a hard link that points to another file. With this hard link created, we can move file3 into another location on the filesystem and it will still be a link to file1. Hard links have a couple of limitations, however. First, you cannot create a hard link to a directory, only a file. Second, this link cannot be moved to a different filesystem. That makes sense, considering each filesystem has its own inodes. Inode 4456458 on my system would of course not point to the same file on another system, if this inode number even exists at all.

To overcome these limitations, we can consider using a symbolic link instead. A symbolic link (also known as soft links or symlinks) is an entry that points to another directory or file. This is different to a hard link, because a hard link is a duplicate entry that references an inode, while a symbolic link references a specific path. Symbolic links can not only be moved around between filesystems (as these do not share the same inode number as the original file), we can also create a symbolic link to a directory as well. To illustrate how a symbolic link works, let’s create one. In my case, I’ll delete file3 and recreate it as a symbolic link. We’ll again use the ln command:

rm file3
ln -s file1 file3  

With the -s option of ln, I’m creating a symbolic link. First, I deleted the original hard link with the rm command (which doesn’t disturb the original) and then created a symbolic link, also named file3. If we use ls -i again, we’ll see that file3 does not have the same inode number as file1:

Output of ls -i after creating a symbolic link

That’s not the only thing that’s different in the output, though. Notice that the inode numbers of each file are all different. At this point, the main difference from a hard link should become apparent. A symbolic link is not a clone of the original file; it’s simply a pointer to the original file’s path. Any commands you execute against file3 are actually being run against the target that the link is pointing to.

In practice, symbolic links are incredibly useful when it comes to server administration. However, it’s important not to go crazy and create a great number of symbolic links all over the filesystem. This certainly won’t be a problem for you if you are the only administrator on the server, but if you resign and someone takes your place, it will be a headache for them to figure out all of your symbolic links and map where they lead to. You can certainly create documentation for your symbolic links, but then you’d have to keep track of them and constantly update documentation. My recommendation is to only create symbolic links when there are no other options, or if doing so benefits your organization and streamlines your file layout.

Getting back to the subject of symbolic links versus hard links, you’re probably wondering which one you should use and when to use it. The main benefit of a hard link is that you can move either file (the link or the original) to anywhere on the same filesystem and the link will not break. This is not true of symbolic links; however, if you move the original file, the symbolic link will be pointing to a file that no longer exists at that location. Hard links are basically duplicate entries pointing to the same object, and thus have the same inode number, so both will have the same file size and content. A symbolic link is merely a pointer-nothing more, nothing less.

However, even though I just spoke about the several benefits of hard links, I actually recommend symbolic links for most use cases. They can cross filesystems, can be linked to directories, and are easier to determine from the output where they lead. If you move hard links around, you may forget where they were originally located or which file actually points to which. Sure, with a few commands you can find them and map them easily. But overall, symbolic links are more convenient in the long run. As long as you’re mindful of recreating your symbolic link whenever you move the original file (and you use them only when you need to), you shouldn’t have an issue.

Comments are closed.