The Mediawiki system (the 'software' that runs this site) capitalises all articles. Please note that commands on most UNIX and Unix-like systems are entered in lower case. As an example the article documenting the Ln command would be issued from the command line as 'ln'.
The ln command is used to create links between files and directories on UNIX and Unix-like file systems. It can be used to give the illusion of copying files without the requirement to duplicate the space of really doing so. This means that a file that has been linked to exists physically on the hard drive only once, but can be listed under several different sub-directories.
Before discussing the types of links that the ln command can create, these being 'hard' links and 'symbolic' links, the following example may help explain the concept.
A corporate web server exists hosting several domains; www.example.com, downloads.example.com and support.example.com. The underlying content directories for these sites are separate from each other as follows:
/server/www/ /server/downloads/ /server/support/
The marketing team want a consistent look and feel to the three sites but they also want the ability to make changes without having to copy them to the three directories every time.
As the system administrator you tell marketing to update their design changes in the file www/looknfeel.css and put images in www/images/. You then set-up links to those files in the remaining directories downloads/ and support/ as follows:
%ln www/looknfeel.css downloads %ln www/looknfeel.css support % %mkdir downloads/images %mkdir support/images % %ln www/images/* downloads/images %ln www/images/* support/images
Running the above sequence of ln commands establishes links from the www/looknfeel.css file into both the downloads/ and support/ directories. The file system then gives the illusion of having the same file called 'looknfeel.css' in each directory:
%ls -l www/ drwxr-xr-x 2 www www 512 Apr 21 10:47 images -rw-r--r-- 2 www www 29 Apr 21 10:40 looknfeel.css % %ls -l downloads/ drwxr-xr-x 2 www www 512 Apr 21 10:49 images -rw-r--r-- 2 www www 29 Apr 21 10:40 looknfeel.css % %ls -l support/ total 4 drwxr-xr-x 2 www www 512 Apr 21 10:49 images -rw-r--r-- 3 www www 29 Apr 21 10:40 looknfeel.css
Note that the size and date-stamp of the 'looknfeel.css' file is the same for each directory in is listed in (details highlighted). This is because the links created reference the original within the www/ directory. Therefore any changes made to www/looknfeel.css will be available to the downloads/ and support/ directories immediately. The same applies to the images directory:
%ls -l www/images/ -rw-r--r-- 3 www www 40 Apr 21 10:47 contact.png -rw-r--r-- 3 www www 86 Apr 21 10:47 corporate_large.jpg -rw-r--r-- 3 www www 40 Apr 21 10:46 corporate_logo.png % %ls -l downloads/images/ -rw-r--r-- 3 www www 40 Apr 21 10:47 contact.png -rw-r--r-- 3 www www 86 Apr 21 10:47 corporate_large.jpg -rw-r--r-- 3 www www 40 Apr 21 10:46 corporate_logo.png % %ls -l support/images/ -rw-r--r-- 3 www www 40 Apr 21 10:47 contact.png -rw-r--r-- 3 www www 86 Apr 21 10:47 corporate_large.jpg -rw-r--r-- 3 www www 40 Apr 21 10:46 corporate_logo.png
Once again the size and date-stamps of the image files are the same as those from the original www/images/ directory (details for the file 'contact.png' highlighted).
While changes made to the files linked from the www/ directory affect those in the other directories, as noted above, it is not limited to editing the original files in the www/ directory. Someone in marketing could be working on the support website when they make a change to the support/looknfeel.css linked file. Because this is a link to the original file all they are in fact doing is editing www/looknfeel.css. Therefore any changes from any directory where there are linked files will always edit the original files in www/. This includes the linked image/ sub-directories.
Links such as these are referred to as 'hard links'.
A hard link is created when using the ln without the '-s' option (see 'Symbolic Links' below). This type of link, as implied by the name, is a physical link at the file system level.
When a hard link is established on a file it is the file's unique identity number, known as an 'inode', that is used on the destination's link filename. The inode can be thought of as a serial number assigned to a file or directory as it is created. It is a pointer to the actual file as stored on the physical disk. This is why it is possible to edit both the original and the link file names and change the same originating file - the operating system asks the file system to update a file and the file system uses the inode to do so.
To show the use of the inode using the 'looknfeel.css' file links created in the above example the 'ls' command is used with the '-i' option:
%ls -i www 2378798 images 2378794 looknfeel.css % %ls -i downloads/ 2378801 images 2378794 looknfeel.css % %ls -i support 2378802 images 2378794 looknfeel.css
It can be seen that the looknfeel.css file has the same inode within each directory where-as the inode for the sub-directory images/ is different because they are each unique directories. However the image files within these directories share the same inodes:
%ls -i www/images/ 2378799 contact.png 2378800 corporate_large.jpg 2378797 corporate_logo.png % %ls -i downloads/images/ 2378799 contact.png 2378800 corporate_large.jpg 2378797 corporate_logo.png % %ls -i support/images/ 2378799 contact.png 2378800 corporate_large.jpg 2378797 corporate_logo.png
Moving files using the 'mv' command on hard-linked files is possible because the inode remains the same, regardless of whether the original file name was used or one of it's linked file names. Therefore editing a moved file will affect the contents of the original file.
Copying files using the 'cp' command will duplicate the original file and give the copied file a new inode, regardless of whether the original file name was used or one of it's linked file names. Therefore editing the new file will not affect the contents of the original file.
Removing files using the 'rm' command will remove the file specified, regardless of whether the original file name was used or one of it's linked file names. While it is possible to remove the original file this will not remove the actual contents of it. This is due to each link being counted against the inode of the file. Therefore removing the original reduces the link count by one and as such the file is editable using the remaining linked file names. Until the final link is removed the file will remain.
This property of hard links can be used to great effect with creating a simple backup. Each night a directory's contents can be linked to another directory and should a user later remove a file the link count will ensure the file remains in the backup directory. It would simply be a case of copying the file back to the original directory, since the inode of the original file still exists. Please note that this, in itself, is not a true reliable backup.
Since hard links rely on the file's inode they are limited to the physical slice (often called a 'partition' in other operating systems) of the file system. You could not, for example, link a file from the /tmp/ directory to the /var/ directory if they reside on separate slices.
Symbolic Links (below) are not limited to this restriction.
A symbolic link, sometimes called a soft link in opposition to hard links or sometimes simply symlinks for short, is created when using the ln with the '-s' option. This type of link is similar in functionality to a 'shortcut' concept in the Microsoft Windows range of operating systems.
When a symbolic link to a file is made the ln command creates a small file containing either the physical or relative path to the file being linked to. This is where the similarity with Microsoft's 'shortcuts' concept is derived. A symbolic link can be create in one of two ways:
%cd /server %ln -s www/looknfeel.css relative_path
This establishes a symbolic link using the relative path, that is, the sub-directory within the current directory. Therefore the file 'relative_path' simply contains 'www/looknfeel.css'.
%cd /server %ln -s /server/www/looknfeel.css physical_path
This establishes a symbolic link using the physical path, that is, the entire directory path from the root to the file itself. Therefore the file 'physical_path' contains '/server/www/liiknfeel.css'.
This is how Microsoft's shortcut concept works, for example, 'C:\Program Files\Application\App.exe'.
Symbolic Links (continued)
There are advantages and disadvantages of using relative and physical paths in the creation of symbolic links. One particular advantage, in contrast to the limitation of hard links (see above), is that they can span slices. Other issues are determined when using the following commands:
Moving files using the 'mv' command on symbolic linked files is only possible for those with physical paths because the path from the root directory is noted. Therefore moving a symbolic link with a relative path will result in the loss of the relativity between its original directory and its destination directory, unless the sub-directory it links to is also moved.
Copying files using the 'cp' command will duplicate the symbolic link and not the original file and is only possible for those with the physical path because the path from the root directory is noted (unless copying the symbolic link within the same directory using a different name). Therefore copying a symbolic link with a relative path will result in the loss of relativity between its original directory and its destination directory, unless the sub-directory it links to is also copied.
Removing files using the 'rm' command will remove the file specified, regardless of whether the original file name was used or one of it's linked file names. In contrast to hard links, if the original file is removed, the file no longer exists. This is due to each link being a reference of the original file's location as a physical or relative path and not its file system inode. Therefore removing the original will cause loss of the data stored within it but leave the remaining linked file names. The linked file names will no longer be of any use.
This property of symbolic links can often be seen of Microsoft Windows where an application is un-installed but a shortcut to it remains on the desktop. The physical path is still contained within the link (or shortcut as on Microsoft Windows) despite the original file being removed.
Further examples of both hard and symbolic links can be seen on the file system of a running FreeBSD operating system.
When installing the perl programming language interpreter the installation process creates various links as the following example illustrates:
%cd /usr/local/bin % %ls -i perl* 1790854 perl 1790854 perl5 1792306 perlbug 1792308 perldoc 1792982 perl-after-upgrade 1790854 perl5.8.8 1792307 perlcc 1792309 perlivp
The version of perl installed was 5.8.8, and forms part of the original file name 'perl5.8.8'. This is hard linked with file names 'perl5' and simply 'perl', as seen by the common inode.
The reason for these links is for application compatibility. It is possible a piece of perl script to be executed with the command 'perl', 'perl5' or even 'perl5.8.8' though most typically the first one would be used. Therefore regardless of the version installed a programmer knows that executing simply 'perl' will start which-ever version it happens to be. Moving up one level the same programmer could have a version of perl from the 4.x.x release and from the 5.x.x release on the same system. They then have the ability to just call 'perl4' or 'perl5' without needing to know the actual file name that application takes from the version number (which would be 'perl5.8.8' in this example). If two versions were installed only one could be hard linked to the simple 'perl' name.
There are other commands present within the same directory that are linked as the following example illustrates:
%cd /usr/local/bin %ls -l lrwxr-xr-x 1 root wheel 16 Nov 14 17:05 autoconf -> autoconf-wrapper lrwxr-xr-x 1 root wheel 16 Nov 14 17:05 autoheader -> autoconf-wrapper lrwxr-xr-x 1 root wheel 16 Nov 14 17:05 autom4te -> autoconf-wrapper lrwxr-xr-x 1 root wheel 16 Nov 14 17:05 autoreconf -> autoconf-wrapper lrwxr-xr-x 1 root wheel 16 Nov 14 17:05 autoscan -> autoconf-wrapper lrwxr-xr-x 1 root wheel 16 Nov 14 17:05 autoupdates -> autoconf-wrapper lrwxr-xr-x 1 root wheel 16 Nov 14 17:05 ifnames -> autoconf-wrapper lrwxr-xr-x 1 root wheel 10 Nov 19 13:02 ldapadd -> ldapmodify lrwxr-xr-x 1 root wheel 13 Nov 14 16:39 libpng12-config -> libpng-config lrwxr-xr-x 1 root wheel 24 Nov 14 16:36 perl5 -> /usr/local/bin/perl5.8.8 lrwxr-xr-x 1 root wheel 5 Nov 19 13:26 zipinfo -> unzip
This list is filtered to show only the linked file names.
The file name on the left is the linked name for the file name on the right, as denoted by the textual arrow '->'. The majority of the symbolic links here link to autoconf-wrapper. If a system administrator called the command 'ldapadd' the operating system would really run the command 'ldapmodify' (highlighted above). Like the 'perl' example above, these links exist for compatibility.