The ln (link) command

Author: Daniel S. Washko

Syntax: ln [option] [target] [link name]


-b, --backup[=Control]: Backup each existing destination file
-d, -F, --directory: Hard link directories (super-user only)
-f, --Force: Remove existing destination file(s)
-n, --no-dereference: Treat destination that is a symlink to a directory as if it were a normal file.
-i, --interactive: Prompt whether to remove destinations
-s, --symbolic: Make symbolic links instead of hard links -S [suffix], --suffix=[Suffix]: Override the usual backup suffix. See below
-target-directory=[directory]: Specify the directory in which to create the links.
-v, --verbose: Print name of each file before linking.
-V [Method], --version-control=[Method]: See below
--help: Display help and exit
--version: Output version information and exit

The default suffix is '~' which can be overridden by the -S option or the SIMPLE_BACKUP_SUFFIX variable in the default login profile or user profile.

Version control can overide the environmental option set with the VERSION_CONTROL variable. The VERSION_CONTROL variable must be set in the default login profile or the individual user profiles. When specified in the ln command, version-control overrides the environmental setting. The options for version control are:

What it does: The ln command is used to create either a "hard link" or a "symbolic link" between files and/or directories.

To understand how links work requires some basic knowledge of how Linux handles files. Each file is assigned unique properties (i.e.; permissions, creation date, file type) when created. The two properties critical to understanding links are inode number and file name. An inode number is a unique number assigned to a file by the operating system at the time the file is created. The inode number corresponds to the location of the file contents (the actual data that makes up the file) on the mounted volume (the partition of the disk that is mounted to the volume the file is created in). The file name is a link to the inode number. The file name points back to the inode number from its (the file name's) location in the directory hierarchy. What this means is that when a file is created two things occur: 1) An inode number is assinged to the file data stored on the disk, and 2) The file name is created in the directory structure and assigned to the inode number.

The inode number (the file contents) can have any number of file names hard linked to it. The ls -l command will report the number of hard linked file names to the coressponding inode number in second field of output (the field after permissions). The ls command will not tell you what other file names are hard linked to the inode number. Also note that this number reports the number of hard links for files only. If the number is in the row of a directory, the this is the number of directories immediately under the indicated directory. This number will always be 2 or more. Remember that . and .. are counted in this number (execute ls -a in any directory, count the directory files, then pop up one level, ls -l and see that the number calculated equals the number in the second field).

When a file name is deleted from the directory tree, the file name's connection to the inode number is severed. If the file name is the last "link" to the inode number, thereby reducing the number of inode (file content) "links" to file names to 0, then the inode is detatched from the actual data and returned to the pool of free inode numbers. The data remains on the disk, but unaccessable by traditional means now that it no longer has a corresponding inode number. The disk space is free to be overwritten. This process is called unlinking.

A hard link creates an indistinguishable link between two file names. A hard link allows two (or more) file names to point to the same inode number. When a hard link is created, the link file is assigned the same inode number as the target in its new directory (or the same directory location if the link name is different from the target). The original file contents remain unchanged, but the new file name is attatched to the inode number corresponding to the file contents. Any change made to either file name is reflected in file data. Essentially, a hard link creates another file name and attatches it to the inode number of the data you want to add the link to. If you delete either file name, the other will remain (basically, you are unlinking the file name from the inode number and removing the file name from the directory tree). Hard links cannot be used to link directories (unless the -d,-F option is used by super user). They cannot be used to link across different file systems. Hard links are restricted to the current mounted disk volume boundary.

When a hard link is created, there is no indication, other than identical inode numbers, that the file is linked to a target. For example: If a file called new is created in a directory called linktest, and a directory is made within the linktest directory called music, and in music we hard link a file called wave to new using this command:

ln ../new wave
we would see no indication that the two files are linked using the command: ls -al. The only way to see that the files are linked is to use the -i (inode) option with ls in the linktest directory to see that the files new and wave share the same inode number.
ls -i *
97781 new
97781 wave

Symbolic links (supported by kernels later than System V release 3) link one (or more) files to a target file. The file name is actually connected to the target file name and not the inode number of the data (like a hard link). All changes made to the links are reflected in the target file, not the link. The only exception is if you delete the link, the target file will not be altered. If you delete the target file the link(s) will no longer be useful since the (their) target is gone. Symbolic links will work on directories. Think of symbolic links as short-cuts. You can create a symlink to a file which does not exist (you cannot do this with a hard link). Symlinks can cut across volume boundaries.

Permission bits are not used on symlinks. The symlink retains the permission of the file it is linked to but will report rwxrwxrwx when called by ls -l.

Unlike hard links, symlinks will be reported by the ls command. For instance, if we create a file in the linktest directory called 80s and then create a symlink in the music directory called band like this:

ln -s ./80s band
This is the output of the ls -l * on the linktest directory:
-rw-rw-r-- 1 owner group date time 80s
-rw-rw-r-- 2 owner group date time new

lrwxrwxrwx 1 owner group date time band -> ../80s
-rw-rw-r-- 2 owner group date time wave

Note: The output of ls -l * reported the file type as l (for link) in the permissions for the band file. Also note that it seems everyone is given rwx permissions for band, but in actuality the symlink retains the permissions of its target file. The band file also has a pointer to its target 80s in the directory one step up. There is no indication in this output that wave is hardlinked to new.


ln /storage/test test
This will create a file test in the current directory that is hardlinked to the file test in the /storage directory. Neither file will be distinguishable from the other. Changes made to either file will reflect in the other. If you delete one of the files, the other will remain.

ln -s /storage/test test
This symbolically links the newly created file test in the current directory with the file test in the /storage directory. Any changes made to the symbolic link test will be reflected in /storage/test. If the symlink file test is deleted, nothing happens to /storage/test. If /storage/test is deleted, then the link becomes dead.

ln -s -b -S old /htdocs /usr/local/apache/htdocs
In this example, a directrory is created in /usr/local/apache/ called htdocs. In this case, the original directory called htdocs in this location is backuped up to htdocs.old and a new file is created called htdocs. This file is symbolically linked to /htdocs which is at the root. Any changes made to /usr/local/apache/htdocs are actually made to /htdocs. This example reflects what was done on the web server. By default the Apache Webserver looks to /htdocs in its own directory for web pages and cgi-bin files. To allow for more space, a partition was created on another hard disk and mounted as /htdocs at root. The /usr/local/apache/htdocs/ directory was symlinked to /htdocs to allow more space for html documents without having to alter the Apache configuration files.