É '..' realmente um link físico?

Depende do sistema de arquivos. A maioria dos sistemas de arquivos segue o design tradicional do Unix, onde .e ..são hard link. A contagem de hard link de um diretório é 2 + n onde n é o número de subdiretórios: essa é a entrada no pai do diretório, a própria .entrada do diretório e ..a entrada de cada subdiretório. A contagem de hard link é atualizada cada vez que um subdiretório é criado, removido ou movido para dentro ou fora do diretório. Consulte Por que um novo diretório tem uma contagem de hard link de 2 antes que qualquer coisa seja adicionada a ele? para uma explicação mais detalhada.

Alguns sistemas de arquivos se desviam dessa tradição, em particular o btrfs .

sabemos que hard links não podem apontar para diretórios

Este é um texto impreciso. Mais precisamente, você não pode criar um link físico para um diretório usando o lnutilitário ou a linkchamada do sistema ou um método semelhante, porque o kernel o impede. A chamada mkdircria um link físico para o pai do novo diretório. É a única maneira de criar um novo link físico para um diretório em um sistema de arquivos (e, inversamente, remover um diretório é a única maneira de remover um link físico para um diretório).

Além disso, observe que é enganoso pensar em links físicos em termos de “apontar para” um arquivo principal. Os links físicos não são direcionais, ao contrário dos links simbólicos. Quando um arquivo tem vários links físicos, eles são equivalentes. Após a seguinte sequência:

mkdir a b
touch a/file
ln a/file b/file

não há nada no sistema de arquivos que se torne b/filesecundário para a/file. As duas entradas de diretório referem-se ao mesmo arquivo. Ambos são links físicos para o arquivo.

Este é um detalhe de implementação.

Em sistemas de arquivos compatíveis com POSIX, ..atua como um hard link.

No entanto, alguns sistemas de arquivos apenas emulam isso e não o armazenam em disco.

Para fins funcionais, a distinção é discutível, supondo que você não tenha corrupção do sistema de arquivos. (Se você fizer isso, o fsck foi projetado para corrigir isso.)

Uma das falhas não-posix para emular totalmente os hard links é que a contagem do hardlink não indica o número correto de subdiretórios dentro de um diretório. A findopção -noleafopção desativa uma otimização que usa essa contagem de links.

Como complemento à resposta de Gilles , acho que vale a pena chamar a atenção para estas palavras e expandi-las:

Além disso, observe que é enganoso pensar em links físicos em termos de “apontar para” um arquivo principal.

É muito importante entender o modelo conceitual de arquivos no linux onde cada nome dentro de um diretório é um "link" apontando para um "inode" que pode apontar para dados.

O que é confuso aqui é a convenção de nomenclatura de "Hard Link" e "Symbolic Link" soando como dois sabores da mesma coisa. Eles não são!

Um arquivo normal é:

link -> x 
        | Inode -> Data

Um "arquivo com link físico" não é diferente:

link_a -> x
          | Inode -> Data
link_b -> x

Mas um link simbólico é:

original_file_name -> x
                      | Inode -> Data

sym_link_name      -> x
                      | Inode -> File name "original_file_name"

Então, por que você não pode vincular diretórios?

A melhor explicação que eu vim é derivada disso . A ..entrada deve ser mantida dentro do diretório. Se você tivesse mais de um único nome apontando para o próprio diretório, poderia ter mais de um pai e isso seria impossível porque ..só pode existir uma vez, como todos os outros nomes possíveis só podem existir uma vez dentro de um diretório.

.e ..são Hard Links Especiais para Inodes

De um ponto de vista puramente pragmático, .. é um hard link. No Linux, ele é tratado como um link físico para o ponto de montagem quando chamado a partir do nível superior de um volume montado, e no Linux e macOS /links físicos para ambos .e ..para o inode 2 como um caso especial.

Mais detalhes

Como outros apontaram, .ambos ..são links físicos para inodes em sistemas de arquivos que suportam inodes. Existem alguns sistemas de arquivos que não possuem inodes , mas isso é um problema secundário. Para fins práticos, quer um sistema suporte inodes diretamente ou não, um hard link apenas aponta para o mesmo bloco de metadados em um determinado sistema de arquivos. Às vezes, o hard link é um link real no sistema de arquivos e, às vezes, é sintetizado porque os sistemas POSIX esperam .e ..existem por razões históricas. De qualquer forma, é tratado como um link físico para diretórios, e alguns sistemas de arquivos, como o HFS+, permitem que você faça links físicos de diretórios que não cruzam os limites do sistema de arquivos.

Hard Linking de Diretórios

O MacOS permite que hard links em sistemas de arquivos HFS+ apontem para diretórios, porque essa foi historicamente a maneira como o Time Machine otimizou o uso do disco. No entanto, as versões mais recentes do Time Machine usam sistemas de arquivos APFS e instantâneos do sistema de arquivos, portanto, não há necessidade dessa exceção, exceto a compatibilidade com versões anteriores, e não funciona no APFS. Não confie nisso.

Portanto, geralmente é o próprio sistema de arquivos que determina se um diretório pode ou não ter um link físico ou não. No Ubuntu 22.04, man 1 lndiz que o utilitário ln suporta links de diretório se o sistema permitir:

       -d, -F, --directory
              allow  the  superuser to attempt to hard link directories (note:
              will probably fail due to system restrictions, even for the  su‐
              peruser)

A parte que provavelmente confunde a maioria das pessoas são os pontos de montagem. Se você tiver um disco montado como /mnt/foo, cd /mnt/foo; ls -ld ..aponta para o inode do ponto de montagem, que neste caso seria o inode para /mnt. Ou o link físico para o ..diretório em uma montagem realmente não cruza os limites do sistema de arquivos porque está apenas olhando para o link físico de /mnt/foo (que existe independentemente de um volume estar montado lá ou não) ou é tratado especialmente pelo kernel para suportar volumes montados. Este é provavelmente um detalhe de implementação e não posso apontar para nenhuma fonte de kernel relacionada a ele, mas funcionalmente ainda é tecnicamente um link físico porque ..aponta para um inode em vez de um link suave apontando para um nome de arquivo.

Você pode testar isso por si mesmo com:

cd /
stat .
stat ..

No Linux e no macOS, quando chamado com o -xsinalizador, você verá que ambos .apontam ..consistentemente para o inode 2. Muitos sistemas de arquivos reservam o inode 1 para blocos defeituosos .

Como você pode criar links físicos para diretórios em alguns sistemas de arquivos, incluindo EXT3/4 com debugfs , não é verdade que você não pode vincular diretórios físicos. Geralmente não é suportado para garantir que o gráfico do diretório seja acíclico, e ferramentas como fsck reclamarão sobre diretórios com links físicos diferentes de .e ..em sistemas de arquivos que não suportam links físicos de diretórios para qualquer coisa que não seja o diretório de trabalho atual ( .) e o pai diretório ( ..) como um caso herdado especial.