Esta é apenas uma má ideia, já que não há como diferenciar um link físico de um nome original.
Permitir links rígidos para diretórios quebraria a estrutura do gráfico acíclico direcionado do sistema de arquivos, possivelmente criando loops de diretórios e subárvores de diretório pendentes, o que tornaria o fsck e qualquer outro passeador de árvore de arquivos propenso a erros.
Primeiro, para entender isso, vamos falar sobre inodes. Os dados no sistema de arquivos são mantidos em blocos no disco, e esses blocos são coletados juntos por um inode. Você pode pensar no inode como o arquivo. Inodes não possuem nomes de arquivos, no entanto. É aí que entram os links.
Um link é apenas um ponteiro para um inode. Um diretório é um inode que contém links. Cada nome de arquivo em um diretório é apenas um link para um inode. Abrir um arquivo no Unix também cria um link, mas é um tipo diferente de link (não é um link nomeado).
Um link físico é apenas uma entrada de diretório extra apontando para esse inode. Quando você ls -l , o número após as permissões é a contagem de links nomeados. A maioria dos arquivos regulares terá um link. Criar um novo link físico para um arquivo fará com que ambos os nomes apareçam no mesmo inode. Nota:
% 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
Agora, você pode ver claramente que não existe um link físico. Um link físico é o mesmo que um nome comum. No exemplo acima, test ou test2 , que é o arquivo original e qual é o link físico? No final, você não pode dizer (mesmo por timestamps) porque ambos os nomes apontam para o mesmo conteúdo, o mesmo 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
O -i flag para ls mostra os números de inode no início da linha. Observe como test e test2 têm o mesmo número de inode,
mas test3 tem um diferente.
Agora, se você tivesse permissão para fazer isso para diretórios, dois diretórios diferentes em pontos diferentes no sistema de arquivos poderiam apontar para a mesma coisa. Na verdade, um subdir poderia apontar de volta para seu avô, criando um loop.
Por que esse loop é uma preocupação? Porque quando você está atravessando, não há como detectar que você está em loop (sem manter o controle dos números de inodes à medida que você atravessa). Imagine que você está escrevendo o comando du , que precisa recorrer aos subdiretórios para descobrir o uso do disco. Como du saberia quando atingisse um loop? É propenso a erros e muita contabilidade que du teria que fazer, apenas para executar essa tarefa simples.
Os links simbólicos são uma coisa totalmente diferente, pois são um tipo especial de "arquivo" que muitas APIs do sistema de arquivos tendem a seguir automaticamente. Observe que um link simbólico pode apontar para um destino inexistente, porque eles apontam por nome e não diretamente para um inode. Esse conceito não faz sentido com hard links, porque a mera existência de um "hard link" significa que o arquivo existe.
Então, por que o du pode lidar com links simbólicos facilmente e não com hard links? Pudemos ver acima que os hard links são indistinguíveis das entradas normais de diretório. Os links simbólicos, no entanto, são especiais, detectáveis e ignoráveis!
du percebe que o link simbólico é um link simbólico e o pula completamente!
% 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 .