A pergunta do OP menciona mount --bind
. Uma verificação rápida mostra que ele não modifica a contagem de links para o diretório que está montado. A ligação direta sempre modifica a contagem de links, que você pode ver usando ls -ld
.
Normalmente (na maioria dos sistemas tipo Unix), o número de hardlinks para um diretório será o número de diretórios conectados a esse nome, por exemplo,
".."
(o diretório pai)
"."
(o próprio diretório)
- subdiretórios
Se você ler a (geralmente) mais informativa informações página, você pode descobrir como os outros fizeram:
Oh great, one spends hours tying to find what is wrong only to
discover,
$ info ln
On all existing implementations, you cannot make a hard link to a
directory, and hard links cannot cross filesystem boundaries. (These
restrictions are not mandated by POSIX, however.)
Therefore, kindly say everywhere you say super-user only,
instead say "few systems, super-user only".
embora atualmente esteja redigido
A maioria dos sistemas proíbe a criação de um link físico para um diretório; naqueles em que é permitido, apenas o superusuário pode fazê-lo (e com cuidado, pois a criação de um ciclo causará problemas a muitos outros utilitários). Os links físicos não podem cruzar os limites do sistema de arquivos. (Essas restrições não são obrigatórias pelo POSIX, no entanto.)
Criar (e remover) links diretos para um diretório é um recurso restrito para evitar a perda de arquivos, se um diretório estiver desvinculado. Como as operações de vincular / desvincular na interface do sistema operacional C são simétricas , a vinculação aos diretórios normalmente é feita apenas nas chamadas mkdir / rmdir.
Lembre-se de que grande parte dos coreutils do GNU foi escrita (e documentada) 20 a 30 anos atrás, quando algumas peças de museu reais ainda estavam em uso. Conforme observado em relação ao Hard Link , originalmente não havia chamadas mkdir / rmdir; diretórios foram criados (como uma operação privilegiada) usando links físicos. Tudo isso desapareceu quando as chamadas do sistema foram adicionadas para resolver os problemas mencionados. Mas a documentação continua se referindo a esses sistemas além da memória de seus mantenedores. A opção questionada estava no antecessor fileutils
(que foi combinado com textutils
e shellutils
em meados da década de 90 para formar coreutils
). Alguns itens do changelog podem ajudar a esclarecer a origem do recurso:
Mon Jul 23 16:57:44 1990 David J. MacKenzie (djm at albert.ai.mit.edu)
* cp.c (copy): Make +update operate silently, like +one-file-system.
* ln.c: Add -F as synonym for -d, for SunOS compatibility.
Wed Feb 21 11:13:26 1990 David J. MacKenzie (djm at albert.ai.mit.edu)
* ln.c (error): New function.
(main, do_link): Call error instead of fprintf and exit.
(main): Recognize new -d +directory option to allow superuser to
make hard links to dirs, like the BSD ln -f option.
(do_link): Don't allow hard links to dirs (they are hard to
get rid of -- rmdir and unlink don't do it), unless -d was given.
(usage): Mention -d +directory option.
Assim, você pode ver, por exemplo, que uma das antiguidades para as quais esse recurso era aplicável era o SunOS. A página do manual correspondente dizia o seguinte:
OPTIONS
-f Force a hard link to a directory -- this option is only avail-
able to the super-user.
-s Create a symbolic link or links.
SYSTEM V OPTIONS
-f Force files to be linked without displaying permissions, asking
questions or reporting errors.
-F Force a hard link to a directory -- this option is only avail-
able to the super-user.
-s Create a symbolic link or links.
Conforme observado na documentação, esse recurso (e a opção correspondente não estão no POSIX (e consulte a seção Racional , que explica o motivo) .Em vez disso, o recurso foi movido para um novo comando (fornecido também pelo GNU coreutils) chamado link
. o comando em si é vago; você precisa ler a descrição da chamada de função para obter qualquer uso do padrão, mas o padrão não esclarece as condições em que o comando funcionaria, além de levar adiante a isenção de responsabilidade sobre os privilégios necessários. Para isso, é necessário acessar recursos dependentes do sistema fora do padrão:
A vinculação a um diretório é restrita ao superusuário na maioria das implementações históricas, porque esse recurso pode produzir loops na hierarquia de arquivos ou corromper o sistema de arquivos. Este volume do POSIX.1-2008 continua essa filosofia proibindo link()
e unlink()
fazendo isso. Outras funções poderiam fazê-lo se o implementador projetasse essa extensão.
Não são sistemas que utilizam hardlinks aos diretórios além do número normal (2 mais subdiretórios).
O OSX usa vários hardlinks para diretórios de arquivos comuns . Ele não suporta isso usando ln
(consulte a página do manual ). De acordo com Como o Time Machine funciona , ele faz isso para fornecer as versões usadas para o recurso de backup do Time Machine.
Leitura adicional: