Existe uma desvantagem em excluir todos os links simbólicos quebrados em um sistema?


46

Eu estava executando um script que iterava sobre todos os arquivos no meu sistema Linux e criava alguns metadados sobre eles, e isso gerou um erro ao atingir um link simbólico quebrado.

Sou novato no * nix, mas tenho a idéia principal por trás da vinculação de arquivos e como os links quebrados existem. Tanto quanto eu sei, eles são como o equivalente a lixo na rua. As coisas que um programa que estou removendo não eram inteligentes o suficiente para dizer que o gerenciador de pacotes existia e pertencia a ele, ou algo que foi deixado para trás em uma atualização. No começo, comecei a ajustar o script que estava executando para ignorá-los, e pensei: 'sempre poderíamos excluí-los enquanto estivermos aqui embaixo ...'

Estou executando o Ubuntu 14.04 (Trusty Tahr). Não vejo nenhum motivo para não fazê-lo, mas antes de prosseguir e executar isso no meu sistema de desenvolvimento, existe algum motivo para que isso possa realmente ser uma péssima idéia? Links simbólicos quebrados servem a algum propósito que eu não conheço?


7
Sim: veja a resposta assinalada abaixo. Mais importante, porém, isso não é uma solução para o seu problema: o script precisa funcionar corretamente, não apenas um sistema higienizado. Um sistema pode ser desinfetado no meio milésimo de segundo entre ser desinfetado e a segunda metade do script em execução. Isso também violou o princípio da responsabilidade única e a filosofia do Unix: "faça uma coisa bem".
Ctrl-alt-delor 23/08/14

Respostas:


68

Há muitas razões para links simbólicos quebrados:

  • Um link foi criado para um destino que não existe mais.
    Resolução: remova o link simbólico quebrado.
  • Um link foi criado para um destino que foi movido. Ou é um link relativo que foi movido em relação ao seu destino. (Para não sugerir que links simbólicos relativos sejam uma péssima idéia - muito pelo contrário: links simbólicos absolutos são mais propensos a ficar obsoletos porque o destino foi movido.)
    Resolução: encontre o destino pretendido e corrija o link.
  • Ocorreu um erro ao criar o link.
    Resolução: encontre o destino pretendido e corrija o link.
  • O link é para um arquivo que está em um disco removível, sistema de arquivos de rede ou outra área de armazenamento que não está montada no momento. Resolução: nenhuma, o link não está quebrado o tempo todo. O link funcionará quando a área de armazenamento estiver montada.
  • O link é para um arquivo que existe apenas parte do tempo, por design. Por exemplo, o arquivo é a saída em cache de um processo, que é excluído quando as informações ficam obsoletas, mas apenas recriadas mediante solicitação explícita. Ou o link é para uma caixa de entrada que é excluída quando vazia. Ou o link é para um arquivo de dispositivo que está presente apenas quando o periférico correspondente está conectado. Resolução: nenhuma, o link não está quebrado o tempo todo.
  • O link é válido apenas em uma hierarquia de armazenamento diferente. Por exemplo, é válido apenas em uma prisão chroot ou é exportado por um servidor NFS e válido apenas no servidor ou em alguns de seus clientes.
    Resolução: nenhuma, o link não está quebrado em todos os lugares.
  • O link está quebrado para você, porque você não tem permissão para percorrer um diretório para alcançar o destino, mas não está quebrado para usuários com privilégios apropriados.
    Resolução: nenhuma, o link não está quebrado para todos.
  • O link é usado para armazenar informações, como no exemplo de bloqueio do Firefox citado por vinc17 . Um motivo para fazer isso dessa maneira é que é mais fácil preencher um link simbólico atomicamente - não há outra maneira, enquanto o preenchimento de um arquivo atomicamente é mais complexo: você precisa criar o conteúdo do arquivo com um nome temporário, movê-lo para o lugar e lidar com arquivos temporários obsoletos deixados para trás por uma falha. Outro motivo é que os links simbólicos geralmente são armazenados diretamente dentro de seu inode em alguns sistemas de arquivos, o que torna a leitura mais rápida do que a leitura do conteúdo de um arquivo.
    Resolução: nenhuma. Nesse caso, remover o link seria prejudicial.

Se você pode determinar que um link simbólico se enquadra na primeira categoria, então vá em frente e exclua-o. Caso contrário, abster-se.

Um programa que percorre diretórios recursivamente e se preocupa com o conteúdo do arquivo geralmente deve ignorar links simbólicos quebrados.


links simbólicos (normalmente) não estão contidos no diretório pai. No entanto, em alguns sistemas de arquivos, o destino do link é armazenado no inode.
precisa

Lista muito boa. Eu tenho vários links que se enquadram nos tipos 4 e 6. Eles apontam para um sistema de arquivos que eu montei com o SSHFS. Quando o sistema de arquivos não está montado, eles são do tipo 4; quando o sistema de arquivos é montado, apenas eu posso acessá-lo, de modo que eles são do tipo 6 para todos os outros (até o root).
Barmar 27/08/14

Mais um motivo possível para um link simbólico quebrado: um link simbólico para um arquivo real que existe apenas parte do tempo. Por exemplo, em um fluxo de trabalho com caminhos profundos, você pode ter um link simbólico para um arquivo de trabalho (por conveniência) que é excluído quando o fluxo de trabalho é concluído, mas será recriado durante o próximo uso desse fluxo de trabalho. / dev / modem é mais ou menos assim porque o arquivo de dispositivo real para o qual ele aponta só existe quando o dispositivo físico está conectado.
Joe

uma resposta bastante abrangente!
Njzk2

1
@MichaelDurrant Uh? O ponto é que a desvantagem (ou a falta dela) depende de como a ligação simbólica quebrada surgiu.
Gilles 'SO- stop be evil'

19

Não remova cegamente todos os links simbólicos pendentes. Eles podem existir apenas para transportar algumas informações e podem ser mais seguros que os arquivos normais, pois a criação de um link simbólico é atômica.

Por exemplo, o Firefox cria um arquivo de bloqueio "bloqueio" que é um link simbólico cujo valor tem um formato como "endereço_IP: + PID".


1
Assim, um programa pode preencher dinamicamente um arquivo vazio para o qual um desses links simbólicos é um link quebrado, enquanto o programa não está sendo executado ? Ou pode ser apenas uma informação?
blanket_cat

1
@knotech O objetivo de alguns links simbólicos (não necessariamente associados a um programa em execução) pode existir apenas. Seu valor é insignificante ou transmite alguma informação específica; nos dois casos, em geral, eles apontam para nada. Não há arquivo vazio, apenas um link simbólico. Note-se também, como exemplo, o caso de gcc constrói, que criam "selo-bits" links simbólicos apontando para si: gcc.gnu.org/ml/libstdc++/2011-02/msg00014.html
vinc17

6

O fnord e o servidor da Web Gatling usam o sistema de arquivos Unix como banco de dados de configuração (em oposição, digamos, ao Microsoft IIS, que usa o registro do Windows, ou ao Apache, que usa um arquivo de configuração complexo para analisar).

Por exemplo, hosts virtuais são apenas diretórios e criar um novo host virtual é tão simples quanto

mkdir www.example.com:80

Configurando quais arquivos servir?

chmod o+r file_that_should_be_served
chmod o-r secret_passwords

Configurando quais arquivos executar como CGI e quais servir?

chmod a-x plain_file.html
chmod a+x cgi_script.html

E por último (e relevante para esta pergunta): configurando um redirecionamento?

ln -s 'http://www.google.com/?q=awesome+query+site:www.example.com' search.html

Agora você terá um link simbólico search.htmlque aponta para lugar nenhum, mas é crucial para o funcionamento do seu site.


0

Um link simbólico pode apontar para um local ainda vazio, para forçar a criação em um local ou nome específico do sistema de arquivos.

Portanto, não - não os remova cegamente.


0

Uma desvantagem significativa na exclusão de links simbólicos obsoletos é que você perde a referência para onde eles costumavam apontar para os quais pode ser bastante valioso!

Digamos que eu tenha um link simbólico para um arquivo chamado " send_to" que aponte /Users/myname/tmpe suponha que /Users/myname/tmpnão exista.

Com o link simbólico, sei onde o arquivo deveria estar. Por exemplo, neste caso, posso ver que é um diretório temporário e, se precisar corrigi-lo, devo considerar um diretório temporário como destino.

Da mesma forma, um link " my_config" que aponte para /etc/conf_fileque conf_filefique 'ruim' porque o nome foi renomeado para confirm_file ainda é uma informação útil. Se você foi ao /etcdiretório e fez um lse viu que o arquivo chamado conf_fileestava ausente, mas confirmation_fileestava lá, você pode ter informações suficientes para corrigir o link agora.


-2

Citando The Linux Command Line (melhor livro de todos os tempos para iniciantes em Linux, e você pode baixá-lo gratuitamente aqui ):

Imagine este cenário: Um programa requer o uso de um recurso compartilhado de algum tipo contido em um arquivo chamado "foo", mas "foo" tem alterações frequentes da versão. Seria bom incluir o número da versão no nome do arquivo para que o administrador ou outra parte interessada pudesse ver qual versão do "foo" está instalada. Isso apresenta um problema. Se alterarmos o nome do recurso compartilhado, teremos que rastrear todos os programas que possam usá-lo e alterá-lo para procurar um novo nome de recurso sempre que uma nova versão do recurso for instalada. Isso não parece divertido.

Aqui é onde os links simbólicos salvam o dia. Digamos que instalamos a versão 2.6 do "foo", que tem o nome de arquivo "foo-2.6" e, em seguida, criamos um link simbólico chamado simplesmente "foo" que aponta para "foo-2.6". Isso significa que quando um programa abre o arquivo " foo ", na verdade está abrindo o arquivo" foo-2.6 ". Agora todo mundo está feliz. Os programas que dependem de "foo" podem encontrá-lo e ainda podemos ver qual versão atual está instalada. Quando chegar a hora de atualizar para o "foo-2.7", basta adicionar o arquivo ao nosso sistema, excluir o link simbólico "foo" e criar um novo que aponte para a nova versão. Isso não apenas resolve o problema da atualização da versão, mas também permite manter as duas versões em nossa máquina. Imagine que “foo-2.7” tem um bug (malditos desenvolvedores!) E precisamos voltar à versão antiga. Novamente,

Portanto, não, eu não excluiria links simbólicos, pois isso certamente será uma dor de cabeça, e você corre o risco de danificar seriamente seu sistema.


6
O OP não estava defendendo a remoção de links simbólicos em todo o tribunal - apenas links simbólicos quebrados , ou seja, links simbólicos que não apontam para nenhum arquivo existente.
precisa saber é o seguinte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.