Working with Links

Sometimes it’s helpful to create a shortcut to a file. For example, you may want to keep a configuration file in an easy-to-access location, but a piece of software expects to find that file in a specific location. You can use links to create shortcuts to files.

In ​Out of Space with Free Space Left​, you learned about inodes, which are data structures that hold information about filesystem objects such as files and directories. Each inode stores the location of the object’s data on the disk, as well as information like the last modification date and file permissions.

When you create a file, you’re creating a link to an inode. Create a new file named greetings.txt that contains some text:

Now, use the ls -i command to look at the inode associated with the file:

You can create two types of shortcuts, or links, to files. Hard links, which are pointers to the actual inode, and symbolic links, or symlinks, which are links to another file. Hard links only work for files, whereas symbolic links work for files and directories.

You’ll look at hard links first. Using the ln command, create a hard link called salutations that points to greetings.txt:

The order of the arguments is important. The ln command works just like the cp command. The source comes first, followed by the name of the link you want to create.

Now, execute the ls -i command again to view the inodes for greetings.txt and salutations. You’ll see that both entries have the same inode number:

Both of these links point to the same inode. They’re two names for the same reference on disk.

If you delete greetings.txt, the salutations file still exists. Try it out:

Since both greetings.txt and salutations pointed to the same inode, which points to the same location on disk, deleting one doesn’t affect the other.

Now let’s look at symbolic links, or symlinks, which work a little differently. A symlink doesn’t point directly to an inode. It points to an existing file or directory instead. Create a symlink from salutations to greetings.txt:

Now, look at the inodes of both files. They each point to a different inode:

The symlink is an independent filesystem object with its own inode.

Use ls -l to view a long listing for greetings.txt:

The output shows that greetings.txt points to salutations. Also note that the first character on the line is an l, indicating it’s a link.

A symlink is quite similar to a traditional desktop shortcut in a GUI. If you remove the underlying file, it no longer works. Delete the salutations file and then try to view greetings.txt with cat:

The output informs you that there’s no such file, but if you use ls -l, you’ll see that the symlink still exists:

You can restore the functionality of the symlink by re-creating the file to which it points. You can also delete it with rm. Go ahead and delete greetings.txt before moving on.

Unlike hard links, you can use symlinks with directories. One of the most useful uses for this is to give you quick access to deeply nested directory structures.

Create the following directory structure:

You can do that quickly with a little brace expansion:

Use a symlink to create a current directory under app/ that points to the v3 directory:

Now, use the tree command to view the app directory structure and you’ll see your symlink, along with its destination:

You can use the ln -s command to point the symlink to the v1 or v2 directories, or even to a new v4 directory you create later. This way, you only have to think about the app/current directory. This is the process a lot of deployment tools use when you set things up on servers. The web server points to a current directory, and the deployment software places the new version of the application into a new directory and updates the symlink. If anything goes wrong, rolling back means changing the symlink back to the previous directory. In addition, you can use symlinks for logs and configuration files. You can create an app/logs directory that holds the production logs for your application. When you deploy a new version, you can create a symlink in app/current/logs which points to your central app/logs directory. Then when you deploy new versions, re-create the symlink again. Deployment solutions often take care of this piece for you as well, but now you have a deeper understanding of how it works.

You can also use symlinks to manage your shell configuration files, which is something you will look at in Chapter 6, ​The Shell and Environment​.

One last thing we should look at before we move on is how to see more detailed info about files and directories, including how to identify what type of file you’re dealing with.