I'm aware that Linux does not allow hard-linking to a directory. I read somewhere,
that this is to prevent unintentional loops (or graphs, instead of the more desirable tree structure) in the file-system.
that some *nix systems do allow the root user to hard-link to directories.
So, if we are on one such system (that does allow hard-linking to a directory) and if we are the root user, then how is the parent directory entry,
.., handled following the deletion of the (hard-link's) target and its parent?
a (200) \-- . (200) \-- .. (100) \-- b (300) | \-- . (300) | \-- .. (200) | \-- c (400) | \-- . (400) | \-- .. (300) | \-- d (500) <snip> | \-- H (400)
(In the above figure, the numbers in the parentheses are the inode addresses.)
a/H is an (attempted) hard-link to the directory
What should be the reference count stored in the inode 400: 2, 3, or 4? In other words, does hard-linking to a directory increases the reference count of the target directory's inode by 1 or by 2?
If we delete
..entries in inode 400 continue to point to valid inodes 400 and 300, respectively. But what happens to the reference count stored in inode 400 if the directory tree
a/bis recursively deleted?
Even if the inode 400 could be kept intact via a non-zero reference count (of either 1 or 2 - see the preceding question) in it, the inode address corresponding to
.. inside inode 400 would still become invalid!
Thus, after the directory tree
b stands deleted, if the user changes into the
a/H directory and then does a
cd .. from there, what is supposed to happen?
Note: If the default file-system on Linux (ext4) does not allow hard-linking to directories even by a root user, then I'd still be interested in knowing the answer to the above question for an inode-based file-system that does allow this feature.