Есть ли обратная сторона в удалении всех неработающих символических ссылок в системе?

Я запускал скрипт, который перебирал все файлы в моей системе Linux и создавал некоторые метаданные о них, и он выдавал ошибку, когда попадал по неработающей символической ссылке.

Я новичок в * nix, но у меня есть основная идея связывать файлы и как появляются неработающие ссылки. Насколько я знаю, они похожи на мусор на улице. То, что программа, которую я удаляю, не было достаточно умным, чтобы сказать, что менеджер пакетов существует и принадлежит ему, или что-то, что осталось в обновлении. Сначала я начал подправлять скрипт, который я запускаю, чтобы пропустить их, потом подумал: «Ну, мы всегда можем их удалить, пока мы здесь ...»

Я использую Ubuntu 14.04 (Trusty Tahr). Я не вижу никакой причины, чтобы не делать этого, но прежде чем я начну работать над своей системой разработки, есть ли причина, по которой это может быть ужасной идеей? Служат ли сломанные символические ссылки какой-то цели, о которой я не знаю?

Есть много причин для неработающих символических ссылок:

• Была создана ссылка на цель, которая больше не существует.
  Решение: удалите сломанную символическую ссылку.
• Была создана ссылка для цели, которая была перемещена. Или это относительная ссылка, которая была перемещена относительно своей цели. (Не означает, что относительные символические ссылки - плохая идея, а совсем наоборот: абсолютные символические ссылки более склонны к устареванию, потому что их цель перемещена.)
  Решение: найдите предполагаемую цель и исправьте ссылку.
• Произошла ошибка при создании ссылки.
  Решение: найдите нужную цель и исправьте ссылку.
• Ссылка на файл, который находится на съемном диске, в сетевой файловой системе или в другой области хранения, которая в данный момент не смонтирована. Разрешение: нет, ссылка не разорвана. Ссылка будет работать, когда область хранения смонтирована.
• Ссылка на файл, который существует только иногда, по замыслу. Например, файл является кэшированным выводом процесса, который удаляется, когда информация устареет, но воссоздается только после явного запроса. Или ссылка на почтовый ящик, который удаляется, когда пуст. Или ссылка на файл устройства, который присутствует только при подключении соответствующего периферийного устройства. Разрешение: нет, ссылка не разорвана.
• Ссылка действительна только в другой иерархии хранения. Например, он действителен только в изолированной тюрьме или экспортируется сервером NFS и действителен только на сервере или на некоторых его клиентах.
  Разрешение: нет, ссылка не везде разорвана.
• Ссылка не работает для вас, потому что у вас нет разрешения пройти через каталог для достижения цели, но она не нарушена для пользователей с соответствующими привилегиями.
  Разрешение: нет, ссылка не разорвана для всех.
• Ссылка используется для хранения информации, как в примере блокировки Firefox, цитируемом vinc17 . Одна из причин сделать это таким образом, что проще заполнить символическую ссылку атомарно - другого способа нет, тогда как заполнение файла атомарно более сложно: вам нужно создать содержимое файла под временным именем, затем переместить его на место и обрабатывать устаревшие временные файлы, оставленные после сбоя. Другая причина заключается в том, что символические ссылки обычно хранятся непосредственно внутри их inode в некоторых файловых системах, что делает их чтение быстрее, чем чтение содержимого файла.
  Разрешение: нет. В этом случае удаление ссылки будет вредным.

Если вы можете определить, что символическая ссылка попадает в первую категорию, тогда, конечно, продолжайте и удалите ее. В противном случае воздержитесь.

Программа, которая рекурсивно просматривает каталоги и заботится о содержимом файлов, должна обычно игнорировать неработающие символические ссылки.

Не удаляйте вслепую все висячие символические ссылки. Они могут существовать только для переноса некоторой информации и могут быть безопаснее обычных файлов, поскольку создание символической ссылки является атомарным.

Например, Firefox создает файл блокировки «lock», который является символической ссылкой, значение которой имеет вид, подобный «IP_address: + PID».

И fnord, и веб-сервер Gatling используют файловую систему Unix в качестве своей базы данных конфигурации (в отличие, скажем, от Microsoft IIS, которая использует реестр Windows, или 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она не существует.

С символической ссылкой , которую я знаю , где этот файл был предназначен , чтобы быть. Например, в этом случае я вижу, что это временный каталог, и если мне нужно «починить» его, я должен рассмотреть временный каталог как место назначения.

Точно так же ссылка « my_config», указывающая на /etc/conf_fileэто, становится «плохой», поскольку conf_fileона была переименована в файлification_freection, по-прежнему является полезной информацией. Если вы пошли в /etcкаталог и выполнили запрос lsи обнаружили, что названный файл conf_fileотсутствует, но confirmation_fileего там может быть достаточно, чтобы исправить эту ссылку.

Цитата из командной строки Linux (лучшая книга для новичков в Linux, и вы можете скачать ее бесплатно здесь ):

Представьте себе этот сценарий: программе требуется использование какого-либо общего ресурса, который содержится в файле с именем «foo», но «foo» часто меняет версию. Было бы хорошо включить номер версии в имя файла, чтобы администратор или другая заинтересованная сторона могли видеть, какая версия «foo» установлена. Это представляет проблему. Если мы изменим имя общего ресурса, мы должны отследить каждую программу, которая может его использовать, и изменить ее, чтобы искать новое имя ресурса каждый раз, когда устанавливается новая версия ресурса. Это совсем не похоже на веселье.

Здесь символические ссылки сохраняют день. Допустим, мы устанавливаем версию 2.6 «foo», которая имеет имя «foo-2.6», а затем создаем символическую ссылку, называемую просто «foo», которая указывает на «foo-2.6». Это означает, что когда программа открывает файл « foo », фактически он открывает файл« foo-2.6 ». Теперь все счастливы. Программы, которые полагаются на «foo», могут найти его, и мы все еще можем видеть, какая актуальная версия установлена. Когда пришло время обновиться до «foo-2.7», мы просто добавляем файл в нашу систему, удаляем символическую ссылку «foo» и создаем новую, которая указывает на новую версию. Это не только решает проблему обновления версии, но также позволяет нам сохранять обе версии на нашей машине. Представьте, что в «foo-2.7» есть ошибка (чёрт возьми, разработчики!), И нам нужно вернуться к старой версии. Очередной раз,

Так что нет, я бы не стал удалять символические ссылки, так как это, безусловно, вызовет головную боль, и вы рискуете серьезно испортить вашу систему.