Hard links to directories aren't fundamentally different to hard links for files. In fact, many filesystems do have hard links on directories, but only in a very disciplined way.
In a filesystem that doesn't allow users to create hard links to directories, a directory's links are exactly
- the
. entry in the directory itself;
- the
.. entries in all the directories that have this directory as their parent;
- one entry in the directory that
.. points to.
An additional constraint in such filesystems is that from any directory, following .. nodes must eventually lead to the root. This ensures that the filesystem is presented as a single tree. This constraint is violated on filesystems that allow hard links to directories.
Filesystems that allow hard links to directories allow more cases than the three above. However they maintain the constraint that these cases do exist: a directory's . always exists and points to itself; a directory's .. always points to a directory that has it as an entry. Unlinking a directory entry that is a directory only removes it if it contains no entry other than . and ...
Thus a dangling .. cannot happen. What can go wrong is that a part of the filesystem can become detached. If a directory's .. pointing to one of its descendants, so that ../../../.. eventually forms a loop. (As seen above, filesystems that don't allow hard link manipulations prevent this.) If all the paths from the root to such a directory are unlinked, the part of the filesystem containing this directory cannot be reached anymore, unless there are processes that still have their current directory on it. That part can't even be deleted since there's no way to get at it.
GCFS allows directory hard links and runs a garbage collector to delete such detached parts of the filesystem. You should read its specification, which addresses your concerns in details. This is an interesting intellectual exercise, but I don't know of any filesystem that's used in practice that provides garbage collection.
If the inode isn't linked to any name and marked as free (number of links zero), it is free and liable to be reused at any time, this type of operation just makes no sense in this case. If it isn't marked as free (number of links not zero), the filesystem is corrupt, and fsck(8) is mandatory.
Some filesystems sport some form of "editor", mostly used for debugging (and people who find Russian roulette boring).
Best Answer
The names for the file are stored in the directory.
In simple terms, a directory on Linux is just a mapping of names to inodes. When you use
mvto rename/move a file, only the mappings in the directories change. This allows you to have hard links to the same inode with different names as long as the hard links are on the same file system partition.More info here.