This is just a bad idea, as there is no way to tell the difference between a hard link and an original name.
Allowing hard links to directories would break the directed acyclic graph structure of the filesystem, possibly creating directory loops and dangling directory subtrees, which would make fsck and any other file tree walkers error prone.
First, to understand this, let's talk about inodes. The data in the filesystem is held in blocks on the disk, and those blocks are collected together by an inode. You can think of the inode as THE file.
Inodes lack filenames, though. That's where links come in.
A link is just a pointer to an inode. A directory is an inode that holds links. Each filename in a directory is just a link to an inode. Opening a file in Unix also creates a link, but it's a different type of link (it's not a named link).
A hard link is just an extra directory entry pointing to that inode. When you ls -l, the number after the permissions is the named link count. Most regular files will have one link. Creating a new hard link to a file will make both filenames point to the same inode. Note:
% ls -l test
ls: test: No such file or directory
% touch test
% ls -l test
-rw-r--r-- 1 danny staff 0 Oct 13 17:58 test
% ln test test2
% ls -l test*
-rw-r--r-- 2 danny staff 0 Oct 13 17:58 test
-rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2
% touch test3
% ls -l test*
-rw-r--r-- 2 danny staff 0 Oct 13 17:58 test
-rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2
-rw-r--r-- 1 danny staff 0 Oct 13 17:59 test3
^
^ this is the link count
Now, you can clearly see that there is no such thing as a hard link. A hard link is the same as a regular name. In the above example, test or test2, which is the original file and which is the hard link? By the end, you can't really tell (even by timestamps) because both names point to the same contents, the same inode:
% ls -li test*
14445750 -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test
14445750 -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2
14445892 -rw-r--r-- 1 danny staff 0 Oct 13 17:59 test3
The -i flag to ls shows you inode numbers in the beginning of the line. Note how test and test2 have the same inode number,
but test3 has a different one.
Now, if you were allowed to do this for directories, two different directories in different points in the filesystem could point to the same thing. In fact, a subdir could point back to its grandparent, creating a loop.
Why is this loop a concern? Because when you are traversing, there is no way to detect you are looping (without keeping track of inode numbers as you traverse). Imagine you are writing the du command, which needs to recurse through subdirs to find out about disk usage. How would du know when it hit a loop? It is error prone and a lot of bookkeeping that du would have to do, just to pull off this simple task.
Symlinks are a whole different beast, in that they are a special type of "file" that many file filesystem APIs tend to automatically follow. Note, a symlink can point to a nonexistent destination, because they point by name, and not directly to an inode. That concept doesn't make sense with hard links, because the mere existence of a "hard link" means the file exists.
So why can du deal with symlinks easily and not hard links? We were able to see above that hard links are indistinguishable from normal directory entries. Symlinks, however, are special, detectable, and skippable!
du notices that the symlink is a symlink, and skips it completely!
% ls -l
total 4
drwxr-xr-x 3 danny staff 102 Oct 13 18:14 test1/
lrwxr-xr-x 1 danny staff 5 Oct 13 18:13 test2@ -> test1
% du -ah
242M ./test1/bigfile
242M ./test1
4.0K ./test2
242M .
The filesystem on macOS (HFS+) does not support hard links to symbolic links:
$ touch file
$ ls -l file
-rw-r--r-- 1 kk staff 0 Jun 17 18:35 file
$ ln -s file slink
$ ls -l file slink
-rw-r--r-- 1 kk staff 0 Jun 17 18:35 file
lrwxr-xr-x 1 kk staff 4 Jun 17 18:36 slink -> file
The following would ordinarily create a hard link to a symbolic link, and is even documented in the ln manual on macOS to do so (EDIT: no it isn't, unless you have GNU coreutils installed and read the wrong manual, doh!):
$ ln -P slink hlink
$ ls -l file slink hlink
-rw-r--r-- 1 kk staff 0 Jun 17 18:35 file
lrwxr-xr-x 1 kk staff 4 Jun 17 18:38 hlink -> file
lrwxr-xr-x 1 kk staff 4 Jun 17 18:36 slink -> file
You can see by the ref count (1) that no new name was created for slink (would have been 2 for both slink and hlink if it had worked). Also, stat tells us that hlink is a symbolic link with 1 inode link (not 2):
$ stat hlink
File: 'hlink' -> 'file'
Size: 4 Blocks: 8 IO Block: 4096 symbolic link
Device: 1000004h/16777220d Inode: 83828644 Links: 1
Access: (0755/lrwxr-xr-x) Uid: ( 501/ kk) Gid: ( 20/ staff)
Access: 2016-06-17 18:38:18.000000000 +0200
Modify: 2016-06-17 18:38:18.000000000 +0200
Change: 2016-06-17 18:38:18.000000000 +0200
Birth: 2016-06-17 18:38:18.000000000 +0200
EDIT: Since I was caught using GNU coreutils, here's the tests again with /bin/ln on macOS:
$ touch file
$ /bin/ln -s file slink
$ /bin/ln slink hlink # there is no option corresponding to GNU's -P
$ ls -l file slink hlink
-rw-r--r-- 2 kk staff 0 Jun 17 18:59 file
-rw-r--r-- 2 kk staff 0 Jun 17 18:59 hlink
lrwxr-xr-x 1 kk staff 4 Jun 17 18:59 slink -> file
The hard link is pointing to file rather than to slink.
On e.g. Linux and OpenBSD (the other OSes I use), it is possible to do this, which results in
$ ls -l file slink hlink
-rw-rw-r-- 1 kk kk 0 Jun 17 18:35 file
lrwxrwxrwx 2 kk kk 4 Jun 17 18:43 hlink -> file
lrwxrwxrwx 2 kk kk 4 Jun 17 18:43 slink -> file
(notice "2")
Best Answer
Don't do this. If you want to have a backup system using hard links to save space, better to use rsync with
--link-dest, which will hard link files appropriately to save space, without causing the problems that this causes (that is, hard linking between directories is a corruption of the filesystem, and will cause it to report wrong inode counts + fail fsck + generally have unknown semantics due to not being a DAG).