C'è un aspetto negativo nell'eliminazione di tutti i collegamenti simbolici interrotti in un sistema?

Stavo eseguendo uno script che scorreva su tutti i file sul mio sistema Linux e creava alcuni metadati su di essi, generando un errore quando colpiva un collegamento simbolico interrotto.

Sono nuovo di * nix, ma ho l'idea principale dietro il collegamento dei file e come nascono i collegamenti interrotti. Per quanto ne so, sono come l'equivalente dei rifiuti in strada. Le cose che un programma che sto rimuovendo non erano abbastanza intelligenti da dire che il gestore dei pacchetti esisteva e apparteneva a esso, o qualcosa che è stato lasciato indietro in un aggiornamento. All'inizio, ho iniziato a modificare la sceneggiatura che sto correndo per saltarli, poi ho pensato: "Beh, potremmo sempre eliminarli mentre siamo quaggiù ..."

Sto eseguendo Ubuntu 14.04 (Trusty Tahr). Non riesco a vedere alcun motivo per non farlo, ma prima di andare avanti e eseguire questo sul mio sistema di sviluppo, c'è qualche motivo per cui questa potrebbe essere davvero una terribile idea? I link simbolici non funzionanti hanno qualche scopo di cui non sono a conoscenza?

Ci sono molte ragioni per i collegamenti simbolici interrotti:

• È stato creato un collegamento a una destinazione che non esiste più.
  Soluzione: rimuovere il collegamento simbolico interrotto.
• È stato creato un collegamento per una destinazione che è stata spostata. Oppure è un collegamento relativo che è stato spostato rispetto al suo obiettivo. (Non implicare che i relativi collegamenti simbolici siano una cattiva idea, anzi il contrario:
  i collegamenti simbolici assoluti sono più inclini a diventare viziati perché il loro obiettivo è stato spostato.) Risoluzione: trova il bersaglio desiderato e correggi il collegamento.
• Si è verificato un errore durante la creazione del collegamento.
  Risoluzione: trova l'obiettivo desiderato e correggi il collegamento.
• Il collegamento è a un file che si trova su un disco rimovibile, un file system di rete o un'altra area di archiviazione che non è attualmente montata. Risoluzione: nessuna, il collegamento non viene interrotto in ogni momento. Il collegamento funzionerà quando l'area di archiviazione è montata.
• Il collegamento è a un file che esiste solo qualche volta, in base alla progettazione. Ad esempio, il file è l'output memorizzato nella cache di un processo, che viene eliminato quando le informazioni diventano obsolete ma ricreate solo su richiesta esplicita. Oppure il collegamento è a una casella di posta che viene eliminata quando vuota. Oppure il collegamento è a un file di dispositivo che è presente solo quando è collegata la periferica corrispondente. Risoluzione: nessuna, il collegamento non viene interrotto in ogni momento.
• Il collegamento è valido solo in una diversa gerarchia di archiviazione. Ad esempio, è valido solo in una jail chroot, oppure viene esportato da un server NFS e valido solo sul server o su alcuni dei suoi client.
  Risoluzione: nessuna, il collegamento non è interrotto ovunque.
• Il collegamento è interrotto per te, perché non hai l'autorizzazione per attraversare una directory per raggiungere la destinazione, ma non è interrotto per gli utenti con privilegi appropriati.
  Soluzione: nessuna, il collegamento non è interrotto per tutti.
• Il collegamento viene utilizzato per archiviare informazioni, come nell'esempio di blocco di Firefox citato da vinc17 . Uno dei motivi per farlo in questo modo è che è più semplice popolare un link simbolico atomicamente - non c'è altro modo, mentre popolare un file atomicamente è più complesso: è necessario creare il contenuto del file con un nome temporaneo, quindi spostarlo in posizione e gestire file temporanei obsoleti lasciati alle spalle da un arresto anomalo. Un altro motivo è che i collegamenti simbolici sono in genere memorizzati direttamente all'interno del loro inode su alcuni filesystem, il che rende la lettura più veloce della lettura del contenuto di un file.
  Risoluzione: nessuna. In questo caso, la rimozione del collegamento sarebbe dannosa.

Se riesci a determinare che un collegamento simbolico rientra nella prima categoria, allora procedi e cancellalo. Altrimenti, astenersi.

Un programma che attraversa ricorsivamente le directory e si preoccupa del contenuto dei file dovrebbe di solito ignorare i collegamenti simbolici interrotti.

Non rimuovere alla cieca tutti i collegamenti simbolici penzolanti. Possono esistere solo per trasportare alcune informazioni e possono essere più sicuri dei normali file poiché la creazione di un collegamento simbolico è atomica.

Ad esempio, Firefox crea un "blocco" di file di blocco che è un collegamento simbolico il cui valore ha una forma come "Indirizzo_IP: + PID".

Sia fnord che il server web Gatling usano il filesystem Unix come database di configurazione (al contrario, diciamo, Microsoft IIS, che utilizza il registro di Windows, o Apache, che utilizza un file di configurazione complessa da analizzare).

Ad esempio, gli host virtuali sono solo directory e la creazione di un nuovo host virtuale è semplice come

mkdir www.example.com:80

Configurare quali file servire?

chmod o+r file_that_should_be_served
chmod o-r secret_passwords

Configurare quali file eseguire come CGI e quali servire?

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

E infine (e pertinente a questa domanda): configurare un reindirizzamento?

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

Ora avrai un link simbolico chiamato search.htmlche punta da nessuna parte, ma è cruciale per il funzionamento del tuo sito.

Un collegamento simbolico potrebbe puntare a una posizione ancora vuota solo per forzare la creazione in una posizione o nome specifico del filesystem.

Quindi no - non rimuoverli ciecamente.

Un aspetto negativo significativo dell'eliminazione di collegamenti simbolici non aggiornati è che si perde il riferimento a dove erano soliti indicare quale può essere abbastanza prezioso!

Supponiamo di avere un link simbolico per un file chiamato " send_to" che indica /Users/myname/tmpe suppone che /Users/myname/tmpnon esista.

Con il collegamento simbolico so dove il file è stato destinato ad essere. Ad esempio, in questo caso posso vedere che si tratta di una directory temporanea e se devo "ripararla", dovrei considerare una directory temporanea come destinazione.

Allo stesso modo un link " my_config" che punta a /etc/conf_filequello diventa 'cattivo' perché il file conf_fileè stato rinominato in file_conferma è ancora informazione utile. Se sei andato alla /etcdirectory e hai fatto un errore e hai lsvisto che il file chiamato conf_filemancava, ma confirmation_fileera lì potresti avere abbastanza informazioni per ora correggere il link.

Citando da Linux Command Line (il miglior libro di sempre per i neofiti di Linux, e puoi scaricarlo gratuitamente qui ):

Immagina questo scenario: un programma richiede l'uso di una risorsa condivisa di qualche tipo contenuta in un file chiamato "pippo", ma "pippo" presenta frequenti cambi di versione. Sarebbe bene includere il numero di versione nel nome del file in modo che l'amministratore o l'altra parte interessata possa vedere quale versione di "pippo" è installata. Questo presenta un problema. Se cambiamo il nome della risorsa condivisa, dobbiamo rintracciare ogni programma che potrebbe usarlo e cambiarlo per cercare un nuovo nome di risorsa ogni volta che viene installata una nuova versione della risorsa. Non sembra affatto divertente.

Qui è dove i collegamenti simbolici salvano il giorno. Diciamo che installiamo la versione 2.6 di "foo", che ha il nome "foo-2.6" e quindi creiamo un link simbolico chiamato semplicemente "foo" che punta a "foo-2.6". Ciò significa che quando un programma apre il file " pippo ”, in realtà sta aprendo il file“ pippo-2.6 ”. Ora tutti sono felici. I programmi che si basano su "pippo" possono trovarlo e possiamo ancora vedere quale versione reale è installata. Quando è il momento di passare a "pippo-2.7", aggiungiamo semplicemente il file al nostro sistema, eliminiamo il collegamento simbolico "pippo" e ne creiamo uno nuovo che punta alla nuova versione. Questo non solo risolve il problema dell'aggiornamento della versione, ma ci consente anche di mantenere entrambe le versioni sul nostro computer. Immagina che "foo-2.7" abbia un bug (accidenti a quegli sviluppatori!) E che dobbiamo tornare alla vecchia versione. Ancora,

Quindi no, non eliminerei i collegamenti simbolici in quanto questo sarà sicuramente un mal di testa che si sposta e corri il rischio di rovinare seriamente il tuo sistema.