システム内の壊れたシンボリックリンクをすべて削除することのマイナス面はありますか？

Linuxシステム上のすべてのファイルを反復処理し、それらに関するメタデータを作成するスクリプトを実行していましたが、壊れたシンボリックリンクにヒットするとエラーがスローされました。

私は* nixに慣れていないが、ファイルのリンクの背後にある主要なアイデアと、壊れたリンクがどのように存在するようになるかを理解している。私の知る限り、それらは路上のゴミに相当します。私が削除しようとしているプログラムが、パッケージマネージャーが存在し、それに属しているか、またはアップグレードで取り残された何かを伝えるほどスマートではありませんでした。最初は、実行中のスクリプトを調整してそれらをスキップし始め、「ここにいる間はいつでも削除できる」と考えました。

Ubuntu 14.04（Trusty Tahr）を実行しています。しない理由はわかりませんが、開発システム上でこれを実行する前に、これが実際にひどいアイデアである可能性がある理由はありますか？壊れたシンボリックリンクは、私が知らない何らかの目的に役立ちますか？

シンボリックリンクの破損には多くの理由があります。

• 存在しないターゲットへのリンクが作成されました。
  解決策：壊れたシンボリックリンクを削除します。
• 移動されたターゲットに対してリンクが作成されました。または、ターゲットに対して相対的に移動された相対リンクです。（相対シンボリックリンクが悪い考えであることを意味するものではありません。まったく逆です。絶対シンボリックリンクは、ターゲットが移動したために古くなる傾向があります。）
  解決策：目的のターゲットを見つけてリンクを修正します。
• リンクの作成時に間違いがありました。
  解決策：目的のターゲットを見つけてリンクを修正します。
• リンクは、リムーバブルディスク、ネットワークファイルシステム、または現在マウントされていない他のストレージ領域にあるファイルへのリンクです。解決策：なし。リンクは常に壊れていません。ストレージエリアがマウントされている場合、リンクは機能します。
• リンクは、設計上、特定の時間にのみ存在するファイルへのリンクです。たとえば、ファイルはプロセスのキャッシュ出力であり、情報が古くなると削除されますが、明示的な要求があった場合にのみ再作成されます。または、リンクが空の場合に削除される受信トレイへのリンクです。または、対応する周辺機器が接続されている場合にのみ存在するデバイスファイルへのリンクです。解決策：なし。リンクは常に壊れていません。
• リンクは、異なるストレージ階層でのみ有効です。たとえば、chroot jailでのみ有効であるか、NFSサーバーによってエクスポートされ、サーバーまたはその一部のクライアントでのみ有効です。
  解決策：なし。リンクはどこでも壊れていません。
• ディレクトリにアクセスしてターゲットに到達する権限がないため、リンクは壊れていますが、適切な権限を持つユーザーの場合は壊れていません。
  解決策：なし。リンクは誰にとっても壊れていません。
• リンクは、vinc17が引用したFirefoxロックの例のように、情報を保存するために使用されます。この方法で行う理由の1つは、シンボリックリンクをアトミックに設定する方が簡単だということです。他の方法はありません。ファイルにアトミックに設定するのはより複雑です。クラッシュによって残された古い一時ファイルを処理します。別の理由は、シンボリックリンクは通常、一部のファイルシステムのiノード内に直接保存されるため、ファイルの内容を読み取るよりも速く読み取ることができるためです。
  解決策：なし。この場合、リンクの削除は有害です。

シンボリックリンクが最初のカテゴリに分類されると判断できる場合は、先に進んで削除してください。そうでなければ、棄権します。

ディレクトリを再帰的に走査し、ファイルの内容を処理するプログラムは、通常、壊れたシンボリックリンクを無視する必要があります。

ぶら下がるすべてのシンボリックリンクを盲目的に削除しないでください。いくつかの情報を伝えるためだけに存在し、シンボリックリンクの作成はアトミックであるため、通常のファイルよりも安全です。

たとえば、Firefoxは、値が「IP_address：+ PID」のような形式のシンボリックリンクであるロックファイル「lock」を作成します。

fnordとGatling Webサーバーはどちらも、構成データベースとしてUnixファイルシステムを使用します（たとえば、Windowsレジストリを使用するMicrosoft IISや、複雑な解析ファイルを使用するApacheとは対照的です）。

たとえば、仮想ホストは単なるディレクトリであり、新しい仮想ホストの作成は次のように簡単です

mkdir www.example.com:80

提供するファイルを構成しますか？

chmod o+r file_that_should_be_served
chmod o-r secret_passwords

CGIとして実行するファイルと提供するファイルを設定しますか？

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

そして最後に（そしてこの質問に関連して）：リダイレクトを設定しますか？

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

search.htmlこれで、どこにも指し示していないシンボリックリンクが作成されますが、サイトの動作には不可欠です。

シンボリックリンクは、特定のファイルシステムの場所または名前で強制的に作成するために、まだ空の場所を指す場合があります。

だから-盲目的にそれらを削除しないでください。

古くなったシンボリックリンクを削除することの大きな欠点は、それらがどこを指していたかの参照が失われてしまうことです。

「send_to」というファイルのシンボリックリンクが/Users/myname/tmpあり、それ/Users/myname/tmpが存在しないことを指し示しているとします。

シンボリックリンクを使用すると、ファイルの場所がわかります。たとえば、この場合、一時ディレクトリであることがわかります。「修正」する必要がある場合は、一時ディレクトリを宛先として考慮する必要があります。

同様に、それがconfirmation_fileに名前変更されたため、my_configそれを指すリンク「」/etc/conf_fileは「不良」になりconf_fileます。あなたはに行ってきました場合は/etc、ディレクトリとやったlsと呼ばれるファイルが見たconf_file欠落していたが、confirmation_fileあなたが今、リンクを修正するのに十分な情報があるかもしれませんでした。

The Linux Command Lineから引用（Linux初心者にとって最高の本であり、ここから無料でダウンロードできます）：

このシナリオを想像してください。プログラムでは、「foo」という名前のファイルに含まれる何らかの種類の共有リソースを使用する必要がありますが、「foo」には頻繁にバージョンが変更されます。ファイル名にバージョン番号を含めると、管理者またはその他の関係者がインストールされている「foo」のバージョンを確認できます。これには問題があります。共有リソースの名前を変更する場合、それを使用する可能性のあるすべてのプログラムを追跡し、新しいバージョンのリソースがインストールされるたびに新しいリソース名を探すように変更する必要があります。それはまったく楽しそうではありません。

ここにシンボリックリンクが1日を節約します。ファイル名が「foo-2.6」である「foo」のバージョン2.6をインストールし、「foo-2.6」を指す単純な「foo」というシンボリックリンクを作成するとします。これは、プログラムがファイル「 foo」、実際には「foo-2.6」ファイルを開いています。今では誰もが幸せです。「foo」に依存するプログラムはそれを見つけることができ、実際にどのバージョンがインストールされているかを見ることができます。「foo-2.7」にアップグレードするときは、ファイルをシステムに追加し、シンボリックリンク「foo」を削除して、新しいバージョンを指す新しいリンクを作成します。これにより、バージョンアップグレードの問題が解決されるだけでなく、マシンに両方のバージョンを保持することもできます。「foo-2.7」にバグがあり（これらの開発者を酷評している！）、古いバージョンに戻す必要があると想像してください。再び、

いいえ、シンボリックリンクは削除しません。これは確かに頭痛の種であり、システムをひどく台無しにするリスクがあります。