2

I'm trying to better understand why directory hardlinks are not possible. Roughly, I think of directories and files as follows:

directory
---------
inode            # exposed as .
inode_of_parent  # exposed as ..
content: 
    mapping from names to inodes
    a hardlink is just another name->inode entry in the mapping

file
----
inode
content

My understanding of directory symlinks is that they are something like:

symlink
-------
inode            # exposed as .  but only if the symlink can be followed
inode_of_parent  # exposed as .. but only if the symlink can be followed
target:
   a named path that, effectively, points to another inode's content

Notably, the target for the symlink does not point to another inode and so it does not increment the link count of any inode. If what the target resolves to is invalid, then the symlink is simply invalid.

I've read Why are hard links to directories not allowed in UNIX/Linux? and it seems to come down mostly to convenience (and presumably performance). [Aside: it seems like '..' effectively breaks the DAG structure anyway, but I guess it does so in a predictable manner, one that hard links would make more complicated.] Some of the comments on that question suggest that it is possible to deal with loops, but for the purposes of discussion, I'm willing to accept that we want to avoid them. Given that, then why could you not have a different kind of symlink that pointed to an inode instead:

alternative symlink
-------------------
inode            # exposed as .
inode_of_parent  # exposed as ..
inode_of_target
is_symlink       # this marks it as special and distinct from a directory

This symlink would have to increment the link count of the target, which makes it robust to moves and renames of the target. So it's basically a hard link, but due to its special flag, it will never be confused as a real directory and so it causes no concerns for loops. The situation seems as manageable.

Obviously, this must be too simple-minded. So I'd like to know why this is not possible. Likely, the story I've told is not sophisticated enough, and so please, complicate it as necessary.

Community
  • 1
Tom
  • 121
  • 1
  • It seems reasonable. I guess the designers just never felt a strong need for something like this. There just isn't a strong use case for directory links that follow renames. – Barmar Dec 12 '14 at 23:02
  • It wouldn't be just for directories. Symlinks to files could follow renames as well. Where this becomes useful, I think, is for some of the user-space implementations of file-tagging systems. In them, you often create symlinks from files to a special directory. But if you rename files, then you must update your symlinks. – Tom Dec 13 '14 at 05:30
  • 1
    You can already do hard links to files, they follow renames. So this would only be useful for directories. These new links would have the same limitation as other hard links, they would be restricted to the same filesystem. – Barmar Dec 13 '14 at 05:34

0 Answers0