Author: Joe Barr
Background: real links and inodes
Real links — a.k.a. “hard” links — simply provide another way to access to the same file, the same data in a file system. The kernel keeps track of files through the use of inodes rather than filenames. Filenames are for wimps, like human users. The kernel don’t need no steenkin filenames.
Quoting from the The Free Dictionary, an inode is:
A data structure holding information about files in a Unix file system. There is an inode for each file and a file is uniquely identified by the file system on which it resides and its inode number on that system. Each inode contains the following information: the device where the inode resides, locking information, mode and type of file, the number of links to the file, the owner’s user and group ids, the number of bytes in the file, access and modification times, the time the inode itself was last modified and the addresses of the file’s blocks on disk.
Links are created using the ln command. Let’s create one, just for fun. The format is:
ln existing-file-name link-name
For whatever reason, I want to use and refer to an existing file on my hard drive by a new name. The existing file name is symlinks.txt. If you’re curious about what the inode is for symlinks.txt, you can find out by using the -i option of the ls command, like this:
ls -i symlinks.txt
Linux responds to that command by showing the inode for the file:
13713932 symlinks.txt
OK, now lets create a “hard” link to the file. The command to use is:
ln symlinks.txt symlinks.lnk
I can now do whatever I want to the file — edit, delete, copy, move — using either the original file name or the link name. The reason I can do that is that both names now point to the same inode. To prove that, use the ln command again, like this, so it picks up both file names:
ls -i symlinks.*
The system responds:
13713932 symlinks.lnk
13713932 symlinks.txt
Even if you ask the system what kind of files these are — using the file command — you’ll get the same answer. Whether you ask file symlinks.lnk or file symlinks.txt you’ll get the same reply:
symlinks.lnk: ASCII English text, with very long lines
Now let’s move one of those files and see what happens:
mv symlinks.lnk symlinks.new
ls -i symlinks.*
13713932 symlinks.new
13713932 symlinks.txt
As you can see, both the original filename and the hard link are still pointing at the same inode. Now let’s try a symbolic link, and look at how they differ from real links.
Updated: The original version of this piece claimed that deleting the hard link also deletes the original file. That’s not true.
Symbolic links
Creating symbolic links is very similar to creating hard links. Just add the -s option to the command, like this:
ln -s testfile.txt testfile.sym
But what has happened under the covers is very different. For one thing, using the -i argument with the ls command now tells us the symbolic link is not sharing the same inode as the original file. The ls commands shows us now that:
8634716 testfile.sym
8634717 testfile.txt
I can still edit the original file by opening the symbolic link, and changes I make doing that will “stick.” But if I delete the symbolic link, it has no impact on the original file at all. If I move or rename the original file, the symbolic link is “broken,” it continues to exist but it points at nothing.
So why use symbolic links?
Symbolic links are very handy for providing misleading information to persnickity or simply aging applications and installers. If they insist on specific versions of a shared library, for example, and you’ve upgraded past that release, you can easily create a symbolic link with a filename which suggests it is the required version which points to the new version.
Symbolic links also offer a greater degree of safety for the original files since they can be deleted without harming a hair on the inode of the original.
