Existe alguma desvantagem em deletar todos os links simbólicos quebrados em um sistema?

Question

Eu estava executando um script que iterava todos os arquivos do meu sistema Linux e criava alguns metadados sobre eles, e ele gerou um erro quando atingiu um link simbólico quebrado.

Sou novato no * nix, mas tenho a ideia principal de vincular arquivos e como links quebrados passam a existir. Tanto quanto eu sei, eles são como o equivalente a lixo na rua. Coisas que um programa que estou removendo não era inteligente 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, eu comecei a ajustar o script que estou correndo para ignorá-los, então eu pensei, 'bem, poderíamos sempre apagá-los enquanto estamos aqui embaixo ...'

Estou executando o Ubuntu 14.04 (Trusty Tahr). Não vejo motivo para isso, mas antes de prosseguir com o meu sistema de desenvolvimento, há alguma razão para que isso possa ser uma idéia terrível? Os links simbólicos quebrados servem para algum propósito que eu não conheço?

    

Answer 1

Existem muitos motivos 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 alvo. (Não insinuar que os links simbólicos relativos são uma má ideia - muito pelo contrário: os links simbólicos absolutos são mais propensos a ficar obsoletos porque o alvo 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: nenhum, 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: nenhum, o link não está quebrado o tempo todo.
• O link só é válido em uma hierarquia de armazenamento diferente. Por exemplo, ele é válido apenas em uma cadeia chroot ou é exportado por um servidor NFS e é válido apenas no servidor ou em alguns de seus clientes. Resolução: nenhum, 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 alvo, mas ele não é quebrado para usuários com privilégios apropriados.
  Resolução: nenhum, 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 . Uma razão para fazer isso dessa maneira é que é mais fácil preencher um link simbólico atomicamente - não há outra maneira, enquanto que preencher 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 por um acidente. Outra razão é que os links simbólicos são normalmente 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 Neste caso, remover o link seria prejudicial.

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

Um programa que atravessa diretórios de forma recursiva e se preocupa com o conteúdo do arquivo normalmente deve ignorar links simbólicos quebrados.

    

Answer 2

Não remova cegamente todos os links simbólicos pendentes. Eles podem existir apenas para carregar algumas informações e podem ser mais seguros que arquivos normais, já que uma criação de links simbólicos é atômica.

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

    

Answer 3

Tanto o fnord como o Gatling usa o sistema de arquivos Unix como banco de dados de configuração (ao contrário do Microsoft IIS, que usa o registro do Windows, ou 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 serão veiculados?

chmod o+r file_that_should_be_served
chmod o-r secret_passwords

Configurando quais arquivos serão executados como CGI e quais servir?

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

E por último (e relevante para esta questão): configurar um redirecionamento?

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

Você agora terá um link simbólico chamado search.html , que não aponta para lugar algum, mas é crucial para o funcionamento do seu site.

    

Answer 4

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

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

    

Answer 5

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

Digamos que eu tenha um link simbólico para um arquivo chamado " send_to ", que aponta para /Users/myname/tmp e suponha que /Users/myname/tmp não exista.

Com o link simbólico eu sei onde o arquivo foi pretendido para ser. Por exemplo, neste caso, posso ver que é um diretório temporário e, se preciso "consertar", devo considerar um diretório temporário como o destino.

Da mesma forma, um link " my_config " que aponta para /etc/conf_file que é "ruim" porque o conf_file foi renomeado para confirmation_file ainda é uma informação útil. Se você foi para o diretório /etc e fez um ls e viu o arquivo chamado conf_file ausente, mas confirmation_file estava lá, talvez você tenha informações suficientes para corrigir o link.

    

Answer 6

Citando o Linux Command Line (melhor livro de todos os novatos do Linux, e você pode baixá-lo de graça here ):

Picture this scenario: A program requires the use of a shared resource of some kind contained in a file named “foo,” but “foo” has frequent version changes. It would be good to include the version number in the filename so the administrator or other interested party could see what version of “foo” is installed. This presents a problem. If we change the name of the shared resource, we have to track down every program that might use it and change it to look for a new resource name every time a new version of the resource is installed. That doesn't sound like fun at all.

Here is where symbolic links save the day. Let's say we install version 2.6 of “foo,” which has the filename “foo-2.6” and then create a symbolic link simply called “foo” that points to “foo-2.6.” This means that when a program opens the file “foo”, it is actually opening the file “foo-2.6”. Now everybody is happy. The programs that rely on “foo” can find it and we can still see what actual version is installed. When it is time to upgrade to “foo-2.7,” we just add the file to our system, delete the symbolic link “foo” and create a new one that points to the new version. Not only does this solve the problem of the version upgrade, but it also allows us to keep both versions on our machine. Imagine that “foo-2.7” has a bug (damn those developers!) and we need to revert to the old version. Again, we just delete the symbolic link pointing to the new version and create a new symbolic link pointing to the old version.

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