Qual é a diferença entre um link físico e um link simbólico?

Como o título diz, eu gostaria de saber a diferença entre um link físico e um link virtual criado pelo comando ln. O comando man lnfornece informações, mas não responde suficientemente à minha pergunta.

Além disso, seria bom se alguém pudesse fornecer uma configuração em que o link físico possa ser preferível a um link simbólico.

No Linux / Unix, os atalhos são conhecidos como Links

Os links são de dois tipos: links flexíveis (links simbólicos) ou hard links.

1. Links flexíveis (links simbólicos)

   Você pode criar links para arquivos e diretórios e criar links (atalhos) em partições diferentes e com um número de inode diferente do original.

   Se a cópia real for excluída, o link não funcionará .

2. Hard Links

   Links físicos são apenas para arquivos; você não pode vincular a um arquivo em uma partição diferente com um número de inode diferente.

   Se a cópia real for excluída, o link funcionará , pois acessa os dados subjacentes que a cópia real estava acessando.

Pergunta: Como faço para criar um link virtual?

Resposta: É possível criar um link flexível ln -s; primeiro, você precisa definir a fonte e, em seguida, o destino. (Lembre-se de que você precisa definir os caminhos completos da origem e do destino; caso contrário, não funcionará.)

 sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib32/libGL.so.1
             (----------Source-------)             ( Destination )

Como você pode ver, ele tem um inode diferente e pode ser feito em uma partição diferente.

Pergunta: Como faço para criar o Hard link?

Resposta: Um link físico pode ser feito com ln; primeiro, você precisa definir a fonte e, em seguida, o destino. (Lembre-se de que você precisa definir o caminho completo da origem e do destino; caso contrário, não funcionará.)

Digamos que eu tenho um script no /scriptdiretório chamado firefox.

 ls -i # Shows you the inode
 5898242 firefox

 ln /scripts/firefox /scripts/on-fire
       ( Source )    ( Destination )

Como você pode ver, ele tem o mesmo inode. Se eu excluir o original, o link funcionará, e ele funcionará como o original.

Acima, verifico se o link está funcionando e excluo o script original do firefox.

Você pergunta: Seria bom se alguém pudesse fornecer uma configuração em que o link físico possa ser preferível a um link simbólico.

Resposta : Dependendo do layout da partição do disco, os Hard Links têm a limitação de que eles devem estar na mesma partição (-1 ponto) e só podem vincular a arquivos (-1 ponto) ), mas +1 ponto se o original for excluído do link funcionará e funciona como o original.

Por outro lado, um link flexível pode apontar para diretórios ou arquivos (ponto +1) e não há limitação de partição (ponto +1), mas (-1 ponto) se a fonte for excluída, o link não funcionará.

Um hardlink não é um ponteiro para um arquivo, é uma entrada de diretório (um arquivo) apontando para o mesmo inode. Mesmo se você alterar o nome do outro arquivo, um link físico ainda apontará para o arquivo. Se você substituir o outro arquivo por uma nova versão (copiando-o), um link físico não apontará para o novo arquivo. Você só pode ter hardlinks dentro do mesmo sistema de arquivos. Com os hardlinks, você não tem noção dos arquivos e links originais, todos são iguais (pense nisso como uma referência a um objeto). É um conceito de nível muito baixo.

Por outro lado, um link simbólico está realmente apontando para outro caminho (um nome de arquivo); ele resolve o nome do arquivo cada vez que você o acessa através do link simbólico. Se você mover o arquivo, o link simbólico não seguirá. Se você substituir o arquivo por outro, mantendo o nome, o link simbólico apontará para o novo arquivo. Os links simbólicos podem abranger sistemas de arquivos. Com links simbólicos, você tem uma distinção muito clara entre o arquivo real e o link simbólico, que não armazena informações ao lado do caminho sobre o arquivo para o qual aponta.

"Uma imagem vale mais que mil palavras."

E, "Um exemplo vale cem parágrafos ..."

Crie dois arquivos:

$ touch blah1   
$ touch blah2

Insira alguns dados neles:

$ echo "Cat" > blah1
$ echo "Dog" > blah2

E como esperado:

$cat blah1; cat blah2
Cat
Dog

Vamos criar links físicos e virtuais:

$ ln blah1 blah1-hard
$ ln -s blah2 blah2-soft

Vamos ver o que aconteceu:

$ ls -l

blah1
blah1-hard
blah2
blah2-soft -> blah2

Alterar o nome de blah1 não importa:

$ mv blah1 blah1-new
$ cat blah1-hard
Cat

blah1-hard aponta para o inode, o conteúdo do arquivo - que não foi alterado.

$ mv blah2 blah2-new
$ ls blah2-soft
blah2-soft
$ cat blah2-soft  
cat: blah2-soft: No such file or directory

Não foi possível encontrar o conteúdo do arquivo porque o link virtual aponta para o nome que foi alterado e não para o conteúdo.
Da mesma forma, se blah1 for excluído, blah1-hard ainda mantém o conteúdo; se blah2 for excluído, blah2-soft é apenas um link para um arquivo inexistente.

fonte: copiando descaradamente do StackOverflow!

Ambos são ponteiros para arquivos; a diferença é o tipo de ponteiro. Um link simbólico aponta para outro arquivo por nome . Ele possui um bit de modo especial que o identifica como um link simbólico e seu conteúdo é o nome do arquivo real. Por conter apenas um nome, esse nome não precisa realmente existir ou pode existir em um sistema de arquivos diferente. Se você substituir o arquivo nomeado (alterar seu conteúdo sem afetar o nome), o link ainda conterá o mesmo nome e agora apontará para o novo arquivo. Você pode identificar facilmente um link simbólico e ver o nome do arquivo para o qual ele aponta.

Um link físico aponta para o arquivo pelo número do inode. Como tal, os links físicos não são diferentes do que o primeiro nome de um arquivo. Não há nome "real" vs. nome do link físico; todos os links físicos são nomes igualmente válidos para o arquivo. Por esse motivo, o arquivo ao qual você vincula deve realmente existir e estar no mesmo sistema de arquivos em que você está tentando criar o link. Se você excluir o nome original, o link físico ainda apontará para o mesmo arquivo. Como todos os links físicos são nomes igualmente válidos para o arquivo, você não pode olhar para um e ver os outros nomes para o arquivo; Para encontrar isso, você deve procurar todos os arquivos e comparar o número de inodes para encontrar os outros nomes que possuem o mesmo número de inode.

Você pode dizer quantos nomes um arquivo tem da saída de ls -l. O primeiro número após o modo de arquivo é a contagem de links. Um arquivo com mais de um link possui outros nomes em algum lugar e, inversamente, um arquivo com uma contagem de links de apenas 1 não possui (outros) links físicos.

Um link físico pode funcionar apenas no mesmo sistema de arquivos; é simplesmente um nome diferente para o mesmo inode (os arquivos são referenciados internamente por inodes). Um arquivo só será excluído do disco quando o último elo à sua inode se foi (você rmD ou unlinkd o último link). Os hardlinks geralmente funcionam apenas para arquivos, não para diretórios.

Um link simbólico (link simbólico) é um arquivo especial que contém um caminho para outro arquivo. Esse caminho pode ser absoluto ou relativo. os links simbólicos podem funcionar em sistemas de arquivos e até apontar para arquivos diferentes, se você, por exemplo, desconectar um disco rígido externo e substituí-lo por outro, que possui um arquivo diferente no mesmo caminho. Um link simbólico pode apontar para arquivos ou diretórios.

Uma das respostas do outro tópico (agora linkado no topo da sua postagem) menciona esta página, que eu acho que é uma explicação razoavelmente boa de nível médio. Se você está se perdendo na arte ascii, aqui está a versão tl; dr:

• Arquivos padrão são um ponteiro do sistema de arquivos para um inode que, por sua vez, aponta para dados físicos. O componente de arquivo armazena seu link para o sistema de arquivos (essencialmente seu caminho) e um link para o inode.
• Links físicos são como arquivos. Eles são apenas um ponteiro adicional diretamente para um inode.
• Links simbólicos são arquivos separados (incluindo inode e dados separados) que armazenam o caminho do sistema de arquivos em um arquivo.

O kernel e os sistemas de arquivos envolvidos traduzem tudo de forma transparente.

Então, com base nisso:

• Os links físicos permitem apenas a ligação do mesmo sistema de arquivos. Os links simbólicos podem apontar para qualquer caminho.
• Links físicos (essencialmente) apontam para dados absolutos. Os links simbólicos podem apontar para caminhos relativos (por exemplo ../parent.file)
• Por extensão, se você mover o ponteiro de destino de um link físico (o qual, lembre-se, é essencialmente apenas um link físico apontando para um inode), o link físico ainda funcionará. Mover o alvo de um link simbólico normalmente interrompe o link simbólico.
• Resolver um link físico seria mais rápido, mas incomensuravelmente. Essa parte insignificante de velocidade tem o custo de um sistema de arquivos inflexível.

Eu posso ter me confundido um pouco, mas lendo várias coisas, estou lutando para encontrar a diferença entre um arquivo padrão e um hardlink. A maneira como estou lendo é cada arquivo consiste em um link físico (armazenando o nome do arquivo), vinculado a um inode que aponta para dados físicos.

Adicionar um hardlink apenas fornece ao inode um ponteiro adicional baseado no sistema de arquivos. Isso está certo?

Quando usar o Soft Link:

Vincular sistemas de arquivos: se você deseja vincular arquivos entre os sistemas de arquivos, poderá usar apenas links simbólicos / soft links.

Links para o diretório: se você deseja vincular os diretórios, deve usar os Soft links, pois não é possível criar um link físico para um diretório.

Quando usar o Hard Link:

Espaço de armazenamento: os links físicos requerem uma quantidade muito desprezível de espaço, pois não há novos inodes criados durante a criação de links físicos. Nos links flexíveis, criamos um arquivo que consome espaço (geralmente 4KB, dependendo do sistema de arquivos)

Desempenho: o desempenho será um pouco melhor ao acessar um link físico, pois você está acessando diretamente o ponteiro do disco em vez de passar por outro arquivo. Movendo o local do arquivo: Se você mover o arquivo de origem para outro local no mesmo sistema de arquivos, o link físico ainda funcionará, mas o link flexível falhará.

Redundância: Se você deseja garantir a segurança dos seus dados, deve usar o link físico, pois no link físico, os dados são seguros, até que todos os links para os arquivos sejam excluídos, em vez do link físico, você perderá os dados se a instância principal do arquivo for excluída.

A confusão surge quando você tenta encontrar a diferença entre "o nome do arquivo" e um link físico, porque não há nenhum.

Cada arquivo que você cria consiste em dados no disco e um link físico - que é um nome de arquivo em um diretório e um ponteiro para os dados no disco. Fim da história. Quando o último (ou único) link físico é excluído, o sistema operacional sabe que os dados não são mais necessários.

Com isso, você pode ver que os dados reais nunca são excluídos, apenas os links físicos são. E quando ficar suficientemente cheio no disco, os dados podem ser substituídos pelos dados de outro arquivo. Até então, os dados do arquivo excluído podem ser recuperados, mas é meio difícil de encontrar sem o link físico.

Os links simbólicos, como explicado anteriormente, simplesmente informam "há um arquivo nomeado <targetname>em uma pasta denominada <targetfolder>". Eles apontam para o link físico. Eles não sabem onde estão os dados. O link rígido sabe disso.

É muito simples. Os arquivos (e diretórios!) São armazenados nos endereços do dispositivo de bloco (HDD ou o que for). Normalmente você tem um único nome mapeado para um endereço, e é assim que você obtém seu arquivo. Um link físico é um nome de segundo, terceiro etc. mapeado para o mesmo endereço. Um link simbólico se refere ao símbolo - o nome - e, portanto, um segundo nome é mapeado para o primeiro nome. No que diz respeito ao kernel, uma vez que ele lê o destino do link simbólico, ele para e volta ao início com o valor do destino como o nome do arquivo (mais ou menos), de modo que links simbólicos relativos são possíveis, mas são inúteis. O nome do destino não é usado acima do nível do sistema de arquivos, exceto se for consultado explicitamente no código do espaço do usuário.