¿Hay un inconveniente en eliminar todos los enlaces simbólicos rotos en un sistema?

Estaba ejecutando un script que iteraba sobre todos los archivos en mi sistema Linux y creaba algunos metadatos sobre ellos, y arrojó un error cuando golpeó un enlace simbólico roto.

Soy nuevo en * nix, pero tengo la idea principal de vincular archivos y cómo los enlaces rotos llegan a existir. Hasta donde yo sé, son como el equivalente de la basura en la calle. Las cosas que un programa que estoy eliminando no eran lo suficientemente inteligentes como para decir que el administrador de paquetes existía y pertenecía a él, o algo que quedó atrás en una actualización. Al principio, comencé a modificar el script que estoy ejecutando para omitirlos, luego pensé, 'bueno, siempre podríamos eliminarlos mientras estamos aquí ...'

Estoy ejecutando Ubuntu 14.04 (Trusty Tahr). No veo ninguna razón para no hacerlo, pero antes de seguir adelante y ejecutar esto en mi sistema de desarrollo, ¿hay alguna razón por la que esta sea una idea terrible? ¿Los enlaces simbólicos rotos tienen algún propósito que desconozco?

Hay muchas razones para los enlaces simbólicos rotos:

• Se creó un enlace a un objetivo que ya no existe.
  Resolución: elimine el enlace simbólico roto.
• Se creó un enlace para un objetivo que se ha movido. O es un enlace relativo que se ha movido en relación con su objetivo. (No implica que los enlaces simbólicos relativos sean una mala idea, sino todo lo contrario: los enlaces simbólicos absolutos son más propensos a quedarse obsoletos porque su objetivo se movió).
  Resolución: encuentre el objetivo deseado y arregle el enlace.
• Hubo un error al crear el enlace.
  Resolución: encuentre el objetivo deseado y corrija el enlace.
• El enlace es a un archivo que se encuentra en un disco extraíble, sistema de archivos de red u otra área de almacenamiento que no está montada actualmente. Resolución: ninguna, el enlace no está roto todo el tiempo. El enlace funcionará cuando se monte el área de almacenamiento.
• El enlace es a un archivo que existe solo algunas veces, por diseño. Por ejemplo, el archivo es la salida en caché de un proceso, que se elimina cuando la información se vuelve obsoleta, pero solo se vuelve a crear a pedido explícito. O el enlace es a una bandeja de entrada que se elimina cuando está vacío. O el enlace es a un archivo de dispositivo que solo está presente cuando se conecta el periférico correspondiente. Resolución: ninguna, el enlace no está roto todo el tiempo.
• El enlace solo es válido en una jerarquía de almacenamiento diferente. Por ejemplo, solo es válido en una cárcel chroot, o lo exporta un servidor NFS y solo es válido en el servidor o en algunos de sus clientes.
  Resolución: ninguna, el enlace no está roto en todas partes.
• El enlace está roto para usted, porque carece del permiso para atravesar un directorio para alcanzar el objetivo, pero no está roto para los usuarios con los privilegios adecuados.
  Resolución: ninguna, el enlace no está roto para todos.
• El enlace se usa para almacenar información, como en el ejemplo de bloqueo de Firefox citado por vinc17 . Una razón para hacerlo de esta manera es que es más fácil llenar un enlace simbólico atómicamente; no hay otra manera, mientras que llenar un archivo atómicamente es más complejo: debe crear el contenido del archivo con un nombre temporal, luego moverlo a su lugar y manejar archivos temporales obsoletos dejados por un bloqueo. Otra razón es que los enlaces simbólicos generalmente se almacenan directamente dentro de su inodo en algunos sistemas de archivos, lo que hace que leerlos sea más rápido que leer el contenido de un archivo.
  Resolución: ninguna. En este caso, eliminar el enlace sería perjudicial.

Si puede determinar que un enlace simbólico cae en la primera categoría, entonces, seguro, continúe y elimínelo. De lo contrario, abstenerse.

Un programa que atraviesa directorios de forma recursiva y se preocupa por el contenido de los archivos generalmente debe ignorar los enlaces simbólicos rotos.

No elimine ciegamente todos los enlaces simbólicos que cuelgan. Pueden existir solo para transportar cierta información, y pueden ser más seguros que los archivos normales, ya que la creación de un enlace simbólico es atómica.

Por ejemplo, Firefox crea un "bloqueo" de archivo de bloqueo que es un enlace simbólico cuyo valor tiene una forma como "dirección_IP: + PID".

Tanto el fnord como el servidor web de Gatling usan el sistema de archivos Unix como su base de datos de configuración (a diferencia de, por ejemplo, Microsoft IIS, que usa el registro de Windows, o Apache, que usa un archivo de configuración complejo para analizar).

Por ejemplo, los hosts virtuales son solo directorios, y crear un nuevo host virtual es tan simple como

mkdir www.example.com:80

¿Configurar qué archivos servir?

chmod o+r file_that_should_be_served
chmod o-r secret_passwords

¿Configurar qué archivos ejecutar como CGI y cuáles servir?

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

Y por último (y relevante para esta pregunta): ¿configurar una redirección?

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

Ahora tendrá un enlace simbólico llamado search.htmlque apunta a ninguna parte, pero es crucial para el funcionamiento de su sitio.

Un enlace simbólico puede apuntar a una ubicación aún vacía para forzar la creación en una ubicación o nombre de sistema de archivos específico.

Entonces no, no los elimine a ciegas.

Una desventaja significativa de eliminar enlaces simbólicos obsoletos es que pierdes la referencia a donde solían señalar, ¡lo cual puede ser muy valioso!

Digamos que tengo un enlace simbólico para un archivo llamado " send_to" que apunta /Users/myname/tmpy supone que /Users/myname/tmpno existe.

Con el enlace simbólico, sé dónde estaba destinado el archivo . Por ejemplo, en este caso puedo ver que es un directorio temporal y si necesito "arreglarlo", debería considerar un directorio temporal como el destino.

Del mismo modo, un enlace " my_config" que apunta a /etc/conf_fileeso va 'mal' porque el nombre conf_fileha sido renombrado como "archivo_confirmación" sigue siendo información útil. Si fue al /etcdirectorio e hizo una lsy vio que conf_filefaltaba el archivo llamado pero confirmation_fileestaba allí, es posible que tenga suficiente información para arreglar el enlace.

Citando desde la línea de comandos de Linux (el mejor libro para principiantes de Linux, y puedes descargarlo gratis aquí ):

Imagine este escenario: un programa requiere el uso de un recurso compartido de algún tipo contenido en un archivo llamado "foo", pero "foo" tiene cambios frecuentes de versión. Sería bueno incluir el número de versión en el nombre del archivo para que el administrador u otra parte interesada pueda ver qué versión de "foo" está instalada. Esto presenta un problema. Si cambiamos el nombre del recurso compartido, tenemos que rastrear cada programa que pueda usarlo y cambiarlo para buscar un nuevo nombre de recurso cada vez que se instala una nueva versión del recurso. Eso no suena divertido en absoluto.

Aquí es donde los enlaces simbólicos salvan el día. Digamos que instalamos la versión 2.6 de "foo", que tiene el nombre de archivo "foo-2.6" y luego creamos un enlace simbólico simplemente llamado "foo" que apunta a "foo-2.6". Esto significa que cuando un programa abre el archivo " foo ", en realidad está abriendo el archivo" foo-2.6 ". Ahora todos están felices. Los programas que dependen de "foo" pueden encontrarlo y aún podemos ver qué versión real está instalada. Cuando llega el momento de actualizar a "foo-2.7", simplemente agregamos el archivo a nuestro sistema, eliminamos el enlace simbólico "foo" y creamos uno nuevo que apunta a la nueva versión. Esto no solo resuelve el problema de la actualización de la versión, sino que también nos permite mantener ambas versiones en nuestra máquina. Imagine que "foo-2.7" tiene un error (¡malditos sean los desarrolladores!) Y necesitamos volver a la versión anterior. De nuevo,

Entonces, no, no eliminaría los enlaces simbólicos, ya que sin duda será un dolor de cabeza seguir adelante, y corre el riesgo de dañar seriamente su sistema.