ln
From NetBSD Wiki
The ln(1) utility creates a new directory entry (linked file) which has the same modes as the original file. It is useful for maintaining multiple copies of a file in many places at once without using up storage for the copies; instead, a link points to the original copy. There are two types of links; hard links and symbolic links.
Contents |
Symbolic Link
A symbolic link contains the name of the file to which it is linked. The referenced file is used when an open(2) operation is performed on the link. A stat(2) on a symbolic link will return the linked-to file; an lstat(2) must be done to obtain information about the link. The readlink(2) call may be used to read the contents of a symbolic link. Symbolic links may span file systems and may refer to directories.
You are most likely to need symbolic links when you want to create a link to another file.
% ln -s sourcename linkedname
Hard link
A hard link is indistinguishable from a real file. It is simply another entry in a directory which happens to point to an inode that another link points to. Actually, all files are hardlinks.
A link is just an entry in a directory in the filesystem to enable humans to find an inode, which to the system is just a number. From this, it follows that a hardlink can only point to inodes within the same filesystem (which usually means "the same disk partition").
You can see the number of links to a file in the long output form of ls:
$ ls -l -rw-rw-r-- 1 yoda users 0 Jul 28 23:44 foo -rw-rw-r-- 2 yoda users 0 Jul 28 23:44 bar
In the example, the file foo has only one link. It is an "ordinary" file. The file bar has two links (a linkcount of two). This means sometime someone has executed the command
$ ln sourcename bar
But is equally plausible than someone once has executed the command
$ ln bar linkedname
In other words, it is not known if bar was the 'original' file, or the second link to the inode.
Whenever you remove a file, the link count to that inode is decreased by one. As soon as the link count of a file drops to zero, the inode is scheduled for deletion by the kernel. As soon as no process holds references to a file which is scheduled for deletion, the file's blocks are declared "free space" and new files can overwrite this space. All this happens in kernel memory. The on-disk filesystem has already removed the links, so it is only the kernel's in-memory map of the blocks the inode used to occupy that prevents them from being overwritten.
