Por que não criar o link físico (link simbólico) e o link físico no mesmo link?

Question

Eu não uso hardlinks há muito tempo e nunca precisei deles até ser perguntado em uma entrevista. Eu li a diferença deles de symlinks aqui: Qual é a diferença entre um link físico e um link simbólico?

Existe algum motivo específico pelo qual o design não está tendo os dois recursos do symlink e os recursos do hardlink no mesmo link ?

Você deseja apontar para um arquivo. Ok, então você começa com uma funcionalidade de hardlink para cobrir situações em que o nome do arquivo é alterado ou o arquivo é movido . Se hardlink não é válido porque se refere fora do sistema de arquivos ou falha por algum outro motivo tem um fallback , o caminho do arquivo para se referir, em outras palavras, tem um symlink.

Porque o que o usuário de um sistema operacional quer até o final do dia é basta ter um link para um arquivo .

Existe alguma coisa que possa impedir a solução de design acima para links?

    

Answer 1

Eu vejo as seguintes desvantagens:

• com links físicos, não há mais o caminho "original" do arquivo, ou seja, você não consegue distinguir um arquivo de seus links. Costumo usar links como atalhos para arquivos que estão em uma estrutura de diretórios aninhada e bem ordenada, para simplificar a navegação, mas ainda quero poder pesquisar exatamente onde o arquivo está armazenado (já que seu caminho original contém informações).
• O substituto tornaria as coisas confusas para usuários menos avançados. Se você se acostumar com tudo que estiver sendo hardlinked e o arquivo for um link, às vezes, você pode excluir o arquivo no local original porque sabe que os links manterão os dados na unidade. Agora, se o fallback de um link flexível tiver ocorrido, você excluirá seus dados. Claro que o software poderia emitir um aviso, mas para muitos isso poderia aumentar a confusão.

Em geral, não acho que seja uma boa ideia esconder coisas fundamentalmente diferentes do usuário. Para a maioria dos cenários, os soft links estão bem. Na minha experiência, os hard links são principalmente úteis para backups. Por exemplo, dirvish faz uso deles.

    

Answer 2

Eu realmente não entendo o que você quer dizer. Eu acho que você entendeu mal o que são hard links. Primeiro, todos os arquivos são hardlinks. Cada um. Um arquivo é apenas um link apontando para um inode. Um link simbólico, por outro lado, é um link apontando para um hardlink (para um caminho). Como os dois poderiam ser combinados?

Mais ao ponto, a funcionalidade é muito diferente. Considere isto:

$ echo "This is file" > file
$ ln -s file softlink
$ ln file hardlink
$ cat softlink 
This is file
$ cat hardlink 
This is file
$ rm file
$ echo "This is a different file" > file
$ cat softlink 
This is a different file
$ cat hardlink 
This is file

Como você pode ver acima, excluir o arquivo para o qual o hardlink aponta não afeta o hardlink, pois o hardlink está apontando para um inode. O softlink, por outro lado, é alterado quando o destino é excluído e recriado, uma vez que o novo arquivo está apontando para um inode diferente.

Além disso, como os hardlinks apontam para inodes e não para caminhos de sistema de arquivos, eles não podem ser relativos. É muito útil ter um link simbólico apontando, por exemplo, ../../foo . Dessa forma, podemos mover toda a estrutura de diretórios para outro lugar e renomear tudo o que quisermos, mas o link não será interrompido. Então, se nos mudarmos para um diretório diferente, um softlink sempre apontará para um foo que é dois níveis acima. Um hardlink, no entanto, apenas apontará para o inode em que foi criado para apontar e mover o diretório não afetará. Às vezes é isso que queremos e às vezes não é. Ter esse tipo de versatilidade é muito útil.

    

Answer 3

Acho que você está confuso com a palavra "link" em "hardlink" / "softlink" . Apesar da aparente simetria, essas são coisas completamente diferentes.

• Soft links:

  Se você vier de algum background da Microsoft, talvez seja mais fácil dizer isso: um softlink é bem parecido com o que é um atalho. É um arquivo (quase) regular que tem um nome de caminho.

  A única diferença está no Unix, o SO tem alguma mágica para redirecionar os aplicativos automaticamente. Ou seja, quando um aplicativo open() sa file, o sistema operacional verificará o flag S_IFLNK mode no arquivo - se estiver definido, significa que ele contém apenas um caminho para outro arquivo, e o sistema operacional redirecionará a chamada para esse caminho.

• Links físicos:

  Um link físico é apenas um termo técnico para "nome do arquivo" . Quando você "cria um link físico" , apenas adiciona um segundo nome para o mesmo arquivo. Todo o fluxo de trabalho é mais ou menos assim:

  • Quando você cria um arquivo, ele obtém um primeiro nome de arquivo automaticamente.
  • Você pode adicionar nomes de arquivos adicionais, se desejar.
  • Você não pode excluir arquivos no Unix. O comando rm exclui apenas um nome de arquivo. Isso é muito mais óbvio quando você sabe que a operação real que realiza é chamada de unlink() ing
  • Sempre que um arquivo não tiver mais nenhum nome de arquivo, ele será excluído. (*)

  Como um sidenote, os diretórios sempre têm pelo menos dois nomes de arquivos: um em seu pai e um em si ( . ). Além disso, se um diretório tiver subdiretórios, ele terá um hardlink adicional em cada subdiretório, denominado .. .

  Você pode ver a contagem de nomes de arquivos / hardlinks executando ls -l . Segunda coluna na saída.

(*): se algum processo estiver usando o arquivo, a exclusão é adiada até que não seja mais usada. Enquanto isso, você tem um arquivo sem nome, que você não pode ver ou acessar.

    

Answer 4

A idéia que você descreve já existe, na forma do 'Alias' no sistema de arquivos HFS + da Apple. Se você criar um alias para um arquivo, poderá usar esse alias para se referir ao arquivo no futuro. O alias usa uma mistura de inode-equivalente (HFS + não possui inodes como tal), nome de arquivo e ... outras coisas para re-encontrar o arquivo, usando um algoritmo que é deliberadamente não documentado.

Pragmaticamente - ou seja, para a maioria dos usuários não-técnicos - isso funciona muito bem, porque o tipo de nome de arquivo é alterado, e as movimentações de arquivo, que as pessoas fazem na prática são bem tratadas (DWIM e tudo isso); e a natureza não documentada do algoritmo de resolução significa que a Apple tem a liberdade de ajustar a heurística se encontrar algo que funcione melhor. Isso é uma coisa boa, em princípio. Por outro lado, incomoda quem prefere que seus computadores sejam determinísticos , caramba! A Apple não parece atualmente usar o 'alias' em sua documentação técnica.

Eu acho que isso vem sob o título de: experimento interessante - pressionado - não é gratificante.

[É muito difícil encontrar capítulos e versos em aliases do HFS + (sc, eu não consegui encontrar nenhum em 10 minutos de pesquisa, agora), então se alguém faz tem referências, fique à vontade para editar esta resposta.]

    

Answer 5

Antes de começar a usar o Unix, usei o AmigaOS, que possui links que possuem alguns dos aspectos de links simbólicos e de hardlinks. Eu realmente nunca entendi como eles se comportaram.

Então eu tenho que usar sistemas Unix (e mais tarde Linux). Eu encontrei ambos os links simbólicos e hardlinks fáceis de entender por conta própria. Até hoje ainda não entendi a construção híbrida usada para links no AmigaOS.

De um princípio de menor surpresa, acho que a distinção entre links simbólicos e hardlinks é uma construção muito boa. Nenhum deles vem com surpresas.

Mas as duas construções são muito diferentes. O aspecto mais significativo que eles têm em comum é que ambos podem ser criados usando a ferramenta de linha de comando ln .

Eu não posso imaginar como você iria mesclar os dois em um conceito unificado sem torná-lo imensamente complicado. E esse seria o principal argumento contra a mudança do design. É melhor ter recursos separados, cada um dos quais é simples de entender, do que um recurso complicado.

Outro argumento contra a mudança é que há um monte de software projetado para trabalhar com links simbólicos e hardlinks como eles funcionam agora. Todo esse software não seria capaz de lidar com um link híbrido.