Why are hard links not allowed for directories?
I am using Ubuntu 12.04. When I try to create a hard link for any directory, it fails. I can create hard links for files inside file system boundary. I know the reason why we cannot create hardlinks for files beyond file system.
I tried these commands:
$ ln /Some/Directory /home/nischay/Hard-Directory
hard link not allowed for directory
$ sudo ln /Some/Directory /home/nischay/Hard-Directory
[sudo] password for nischay:
hard link not allowed for directoryI just want to know the reason behind this. Is it same for all GNU/Linux distros and Unix flavours (BSD, Solaris, HP-UX, IBM AIX) or only in Ubuntu or Linux?
54 Answers
Directory hardlinks break the filesystem in multiple ways
They allow you to create loops
A hard link to a directory can link to a parent of itself, which creates a file system loop. For example, these commands could create a loop with the back link l:
mkdir -p /tmp/a/b
cd /tmp/a/b
ln -d /tmp/a lA filesystem with a directory loop has infinite depth:
cd /tmp/a/b/l/b/l/b/l/b/l/bAvoiding an infinite loop when traversing such a directory structure is somewhat difficult (though for example POSIX requires find to avoid this).
A file system with this kind of hard link is no longer a tree, because a tree must not, by definition, contain a loop.
They break the unambiguity of parent directories
With a filesystem loop, multiple parent directories exist:
cd /tmp/a/b
cd /tmp/a/b/l/bIn the first case, /tmp/a is the parent directory of /tmp/a/b.
In the second case, /tmp/a/b/l is the parent directory of /tmp/a/b/l/b, which is the same as /tmp/a/b.
So it has two parent directories.
They multiply files
Files are identified by paths, after resolving symlinks. So
/tmp/a/b/foo.txt
/tmp/a/b/l/b/foo.txtare different files.
There are infinitely many further paths of the file. They are the same in terms of their inode number of course. But if you do not explicitly expect loops, there is no reason to check for that.
A directory hardlink can also point to a child directory, or a directory that is neither child nor parent of any depth. In this case, a file that is a child of the link would be replicated to two files, identified by two paths.
Your example
$ ln /Some/Directory /home/nischay/Hard-Directory
$ echo foo > /home/nischay/Hard-Directory/foobar.txt
$ diff -s /Some/Directory/foobar.txt /home/nischay/Hard-Directory/foobar.txt
Files /Some/Directory/foobar.txt and /home/nischay/Hard-Directory/foobar.txt are identical
$ echo bar >> /Some/Directory/foobar.txt
$ diff -s /Some/Directory/foobar.txt /home/nischay/Hard-Directory/foobar.txt
Files /Some/Directory/foobar.txt and /home/nischay/Hard-Directory/foobar.txt are identical
$ cat /Some/Directory/foobar.txt
foo
barHow can soft links to directories work then?
A path that may contain softlinks and even soft linked directory loops is often used just to identify and open a file. It can be used as a normal, linear path.
But there are other situations, when paths are used to compare files. In this case, symbolic links in the path can be resolved first, converting it to a minimal, and commonly agreed upon representation creating a canonical path:
This is possible, because the soft links can all be expanded to paths without the link. After doing that with all soft links in a path, the remaining path is part of a tree, where a path is always unambiguous.
The command readlink can resolve a path to its canonical path:
$ readlink -f /some/symlinked/pathSoft links are different from what the filesystem uses
A soft link cannot cause all the trouble because it is different from the links inside the filesystem. It can be distinguished from hard links, and resolved to a path without symlinks if needed.
In some sense, adding symlinks does not alter the basic file system structure - it keeps it, but adds more structure like an application layer.
From man readlink:
NAME readlink - print resolved symbolic links or canonical file names SYNOPSIS readlink [OPTION]... FILE... DESCRIPTION Print value of a symbolic link or canonical file name -f, --canonicalize canonicalize by following every symlink in every component of the given name recursively; all but the last component must exist [ ... ]"You generally should not use hard links anyway" is over-broad. You need to understand the difference between hard links and symlinks, and use each as appropriate. Each comes with its own set of advantages and disadvantages:
Symlinks can:
- Point to directories
- Point to non-existent objects
- Point to files and directories outside the same filesystem
Hard links can:
- Keep the file that they reference from being deleted
Hard links are especially useful in performing "copy on write" applications. They allow you to keep a backup copy of a directory structure, while only using space for the files that change between two versions. Note that the implementation must first break the link (or modifications will apply to the original file, too!).
The command cp -al is especially useful in this regard. It makes a complete copy of a directory structure, where all the files are represented by hard links to the original files. You can then proceed to update files in the structure (after creating actual copies of only these files), and only the files that you update will take up additional space. This is especially useful when maintaining multigenerational backups.
FYI, you can achieve the same thing as hard links for directories by using mount:
mount -t bind /var/www /home/user/workspace/wwwThis is very dangerous because most tools and programs will not be aware of the binding. I once did something like in the above example and then proceeded to rm -rf /home/user. Luckily, there was nothing relevant in /var/www.
The reason hard-linking directories is not allowed is a little technical. Essentially, they break the file-system structure. You should generally not use hard links anyway. Symbolic links allow most of the same functionality without causing problems (e.g ln -s target link).
