Um link rígido é apenas um nome adicional para um arquivo existente no Linux ou outros sistemas operacionais do tipo Unix.

Um número qualquer de links rígidos, e assim qualquer número de nomes, pode ser criado para qualquer arquivo. Links rígidos também podem ser criados para outros links rígidos. No entanto, eles não podem ser criados para diretórios, e eles não podem cruzar os limites do sistema de arquivos ou atravessar partições.

O sistema operacional não faz distinção entre o nome que foi originalmente atribuído a um arquivo quando ele foi criado pela primeira vez e quaisquer ligações rígidas que são posteriormente criadas para esse arquivo, a não ser que elas sejam apenas múltiplos nomes para o mesmo arquivo. Isto porque o nome original e quaisquer links rígidos apontam todos para o mesmo inode. Um inode é uma estrutura de dados (isto é, uma forma optimizada de armazenar informação) que armazena toda a informação sobre um ficheiro (por exemplo, o seu tamanho, as suas permissões de acesso, quando foi criado e onde está localizado no sistema) excepto o(s) seu(s) nome(s) e os seus dados reais. O fato dos números de inode serem únicos apenas dentro de qualquer sistema de arquivos é a razão pela qual eles não funcionam entre sistemas de arquivos e partições.

Ligações rígidas são criadas com o comando ln. Por exemplo, o seguinte criaria um link rígido chamado hlink1 para um arquivo chamado file1, ambos no diretório atual (ou seja, o diretório no qual o usuário está trabalhando atualmente):

ln file1 hlink1

Quando um link rígido é criado, não há nenhuma indicação óbvia de que ele seja diferente de qualquer outro arquivo. Ou seja, links rígidos parecem ser arquivos do mesmo tipo dos seus arquivos de destino (ou seja, os arquivos aos quais estão ligados) quando são vistos com comandos como ls (ou seja, lista) e arquivo (que é usado para determinar o tipo de qualquer arquivo especificado). Da mesma forma, quando vistos em uma GUI (interface gráfica de usuário), os ícones para links rígidos são idênticos aos dos seus arquivos de destino.

Que o nome inicial de um arquivo e todos os links rígidos para esse arquivo compartilham o mesmo inode podem ser claramente vistos usando o comando ls com sua opção -i (i.e., inode). Assim, por exemplo, o seguinte mostraria que os números de inode do ficheiro1 e hlink1 do exemplo acima são idênticos:

ls -i file1 hlink1

O número de links rígidos para qualquer ficheiro é mostrado na segunda coluna de saída produzida usando ls com a sua opção -l (i.e., longa). Pode-se ver que o número é a soma do arquivo de destino e quaisquer links rígidos para ele (ou seja, a soma do nome inicial e quaisquer nomes adicionados posteriormente) e que é o mesmo para o destino e para cada um desses links.

Arquivos com link rígido também podem ser encontrados usando o comando find com sua opção -type f (para selecionar somente arquivos regulares) seguido pela opção -links +1 (para mostrar todos os arquivos regulares com mais de um link rígido para eles) como segue:

find -type f -links +1

Quando uma alteração é feita no conteúdo de um arquivo, o link para todos os links rígidos é preservado. No entanto, alguns editores de texto podem quebrar o link criando um novo inode para o conteúdo revisto1 e assim pode ser prudente verificar links importantes depois de modificar arquivos.

O comando rm aparece superficialmente para remover ou apagar arquivos. O que ele realmente faz, no entanto, é reduzir a contagem de links difíceis de um arquivo (ou seja, o número de nomes que o arquivo tem) por um, e não afeta diretamente o inode ou os dados do arquivo. Quando a contagem chega a zero, o arquivo parece ter desaparecido porque não há mais nenhuma maneira fácil de referenciá-lo. No entanto, os dados do arquivo só são realmente apagados quando a(s) localização(ões) no disco rígido (HDD) ou outra mídia de armazenamento que o contém é(são) sobrescrita(s) por um novo arquivo.

Assim, por exemplo, o seguinte removeria o link rígido hlink1 que foi criado no exemplo acima:

rm hlink1

Usar rm novamente com o nome restante como a seguir tornaria os dados do arquivo virtualmente inacessíveis:

rm file1

Talvez o aplicativo mais útil para links rígidos seja permitir arquivos, programas e scripts (i.e. programas curtos) possam ser facilmente acessados em um diretório diferente do arquivo original ou arquivo executável (ou seja a versão pronta para ser executada de um programa). Digitar o nome do link rígido fará com que o programa ou script seja executado da mesma forma que usar seu nome original.

Links simbólicos, também chamados soft links, são mais úteis que os hard links porque podem ser feitos tanto para diretórios quanto para arquivos em diferentes sistemas de arquivos e em diferentes partições. Além disso, ao usar uma GUI, links simbólicos têm ícones especiais que os identificam imediatamente como sendo links ao invés de arquivos comuns. No entanto, eles têm a desvantagem de se tornarem inutilizáveis se seu arquivo de destino for excluído.

Aliases superficialmente se assemelham a links rígidos, pois são outra forma de fornecer múltiplos nomes para qualquer arquivo. No entanto, o comando alias é incorporado na shell (ou seja, o programa que fornece a interface de usuário somente texto) ao invés de ser um programa separado e o mecanismo é muito diferente do dos links rígidos. Tal como os links simbólicos, os alias podem ser usados não só para ficheiros mas também para directórios e podem atravessar os limites do sistema de ficheiros e das partições. Além disso, um alias pode ser usado como um nome curto para qualquer texto da shell (ou seja, um comando ou série de comandos ligados, incluindo opções e/ou argumentos tbeir).

________
1Testes no Red Hat Linux 9 descobriram que links rígidos foram quebrados ao modificar arquivos usando o editor de texto gedit. Entretanto, eles não foram quebrados ao usar os editores de texto vi e Abiword, assim como o editor hexadecimal KHexEdit na mesma versão do Linux. A falha do gedit em preservar links rígidos foi devido ao fato de que ele realmente cria uma cópia do arquivo modificado que ele salva (e portanto o novo número do inode) ao invés de fazer as alterações no arquivo original, mas a esta cópia é dado o nome do arquivo original. Entretanto, um teste similar usando uma versão mais recente do gedit (2.14.0) no Fedora Core 5 mostrou que o problema tinha sido corrigido e que não havia quebra de links.