Linux: Como funciona o hard-linking para um diretório?

Question

Estou ciente de que o Linux não permite hard-linking para um diretório. Eu li em algum lugar,

1. que isso é para evitar loops não intencionais (ou gráficos, em vez da estrutura de árvore mais desejável) no sistema de arquivos.

2. que alguns sistemas * nix permitem que o usuário root faça links diretos para diretórios.

Portanto, se estivermos em um desses sistemas (que permitem links rígidos para um diretório) e se formos o usuário root, como a entrada do diretório pai, .. , será manipulada após a exclusão do ( alvo do hard-link) e seu pai?

a (200)
\-- .  (200)
\-- .. (100)
\-- b  (300)
|   \-- .  (300)
|   \-- .. (200)
|   \-- c  (400)
|       \-- .  (400)
|       \-- .. (300)
|       \-- d  (500)

 <snip>

|
\-- H (400)

(Na figura acima, os números entre parênteses são os endereços do inode).

Se a/H for um (hard) link para o diretório a/b/c , então

1. Qual deve ser a contagem de referência armazenada no inode 400: 2, 3 ou 4? Em outras palavras, o hard-linking para um diretório aumenta a contagem de referência do inode do diretório de destino em 1 ou por 2?

2. Se excluirmos a/b/c , as entradas . e .. no inode 400 continuarão apontando para inodes válidos 400 e 300, respectivamente. Mas o que acontece com a contagem de referência armazenada no inode 400 se a árvore de diretórios a/b for recursivamente excluída?

Mesmo se o inode 400 puder ser mantido intacto por meio de uma contagem de referência diferente de zero (de 1 ou 2 - veja a pergunta anterior), o endereço inode correspondente a .. dentro do inode 400 ainda se tornaria inválido!

Assim, após a árvore de diretórios b ser excluída, se o usuário mudar para o diretório a/H e, em seguida, fizer um cd .. , o que deve acontecer?

Observação: Se o sistema de arquivos padrão no Linux (ext4) não permitir links rígidos para diretórios, mesmo que por um usuário root, eu ainda estaria interessado em saber a resposta para o pergunta acima para um sistema de arquivos baseado em inode que permite esse recurso.

    

Answer 1

Links físicos para diretórios não são fundamentalmente diferentes de links para arquivos. De fato, muitos sistemas de arquivos possuem hard links em diretórios, mas apenas de uma maneira muito disciplinada.

Em um sistema de arquivos que não permite que os usuários criem links físicos para diretórios, os links de um diretório são exatamente

1. a entrada . no próprio diretório;
2. as entradas .. em todos os diretórios que têm esse diretório como pai;
3. uma entrada no diretório para o qual .. aponta.

Uma restrição adicional em tais sistemas de arquivos é que, de qualquer diretório, seguir .. nós deve levar à raiz. Isso garante que o sistema de arquivos seja apresentado como uma única árvore. Essa restrição é violada em sistemas de arquivos que permitem links rígidos para diretórios.

Sistemas de arquivos que permitem links para diretórios permitem mais casos do que os três acima. No entanto, eles mantêm a restrição de que esses casos existem: o . de um diretório sempre existe e aponta para si mesmo; o .. de um diretório sempre aponta para um diretório que o contém como uma entrada. Desvincular uma entrada de diretório que é um diretório só a remove se ela não contiver nenhuma entrada diferente de . e .. .

Assim, um .. pendente não pode acontecer. O que pode dar errado é que uma parte do sistema de arquivos pode ser desanexada. Se o .. de um diretório aponta para um de seus descendentes, então ../../../.. forma um loop. (Como visto acima, sistemas de arquivos que não permitem manipulações de link físico impedem isso.) Se todos os caminhos da raiz para tal diretório não estiverem ligados, a parte do sistema de arquivos que contém este diretório não pode mais ser alcançada, a menos que existam processos que ainda tem seu diretório atual nele. Essa parte não pode ser excluída, já que não há como chegar até ela.

O

GCFS permite links diretos de diretório e executa um coletor de lixo para excluir essas partes desanexadas do sistema de arquivos. Você deve ler sua especificação, que aborda suas preocupações em detalhes. Esse é um exercício intelectual interessante, mas não conheço nenhum sistema de arquivos usado na prática que forneça coleta de lixo.

    

Answer 2

A vinculação rígida de um diretório (quando permitido) funciona da mesma maneira que a vinculação rígida de um arquivo simples. Portanto, a vinculação rígida sempre aumenta a contagem de links em um e, assim, na sua pergunta nº 1, a contagem de links aumentaria de 2 para 3.

A questão # 2 é um pouco mais desanimadora, e depende de quão inteligente é o rmdir . Normalmente, se você excluir o diretório a/b/c , o programa "rmdir" será desvinculado

• a/b/c/. - inode 400
• a/b/c/.. - inode 300
• a/b/c - inode 400

Mas lembre-se - c e H são o mesmo diretório (inode), por isso, pode ser mais preciso reformular a lista acima como

• (inode 400)/. - inode 400
• (inode 400)/.. - inode 300
• (inode 300)/c - inode 400

Em outras palavras, as entradas . e .. serão excluídas do inode 400 (conhecido como a/b/c e a/h ), então sua suposição na questão # 2 pode estar errada - o diretório H pode continuar existindo, mas estar completamente vazio (nem mesmo . e .. entradas).

Mas outra possibilidade é que "rmdir" verá que a contagem de links em c é 3 e poderá desvincular apenas a/b/c e não as entradas em c (inode 400). Nesse caso, pense como funciona com arquivos simples. (Eu suponho que você basicamente entende isso.)

• Se você criar o arquivo antelope , vinculá-lo a gazelle e, em seguida, excluir antelope , o arquivo ainda existirá sob o nome gazelle .

• Se você criar o arquivo dir1/antelope , vinculá-lo a dir2/gazelle e, em seguida, excluir dir1/antelope , o arquivo ainda existirá sob o nome dir2/gazelle .

• OK, substitua b por antelope , a por dir1 , .. por gazelle e H por dir2 . Então H/.. (inode 300) continuaria a existir, com uma contagem de links de 1, mas (como no outro cenário) seria completamente vazio (nem mesmo . e .. entradas).

Esse tipo de confusão é o motivo pelo qual os diretórios de hard-linking são strongmente desencorajados.