Существует ли оборотная сторона к удалению всех разорванных символьных связей в системе?
Похоже, что проблема решена. Я просто отключил "быструю загрузку" (или sth эквивалент) опция в меню материнской платы EFI во время процесса начальной загрузки. В результате оптимизации EFI сделал для ускорения начальной загрузки, неполная карта устройства, кажется, передается загрузчику - с информацией о просто целевом жестком диске ОС.
GRUB раньше видел все диски даже с опцией, идущей, если я ввел меню EFI и принял решение загрузить GRUB от него, так по-видимому, оптимизация только влияет на прямые начальные загрузки, те, которые избегают меню. Может быть чувствительным, если Вы имеете большой'>' диски на 1 ТБ с многочисленными разделами для EFI для просмотра.
] Существует множество причин разрыва символических связей:[
] [- ]
[
- ] Была создана связь с целью, которая больше не существует.[
]. Резолюция: удалить сломанную сим-ссылку.[ ]
[ - ]Ссылка была создана для цели, которая была перемещена. Или это относительная ссылка, которая была перемещена относительно цели. (Это не означает, что относительные симлинки - плохая идея, а наоборот: абсолютные симлинки более склонны к застоям, потому что их цель была перемещена)[
]. Резолюция: найти предполагаемую цель и исправить ссылку.[ ]
[ - ]При создании ссылки произошла ошибка.[
]. Резолюция: найти предполагаемую цель и исправить ссылку.[ ]
[ - ]Ссылка на файл, находящийся на съемном диске, в сетевой файловой системе или в другой области хранения, которая в данный момент не смонтирована. Resolution: none, ссылка не прерывается постоянно. Ссылка будет работать, когда будет смонтирована область хранения.[ ] [
- ]Ссылка на файл, который существует только часть времени, по замыслу. Например, файл - это кэшированный результат процесса, который удаляется, когда информация становится неактуальной, но воссоздаётся только по явному запросу. Или ссылка на почтовый ящик, который удаляется, когда информация пуста. Или ссылка на файл устройства, который присутствует только при подключении соответствующей периферии. Resolution: none, ссылка не прерывается постоянно.[ ] [
- ]Ссылка действительна только в другой иерархии хранилища. Например, она действительна только в chroot jail, или экспортируется NFS-сервером и действительна только на сервере или на некоторых его клиентах.[
]. Разрешение: нет, связь не везде нарушена.[ ]
[ - ] Ссылка разорвана для вас, потому что у вас нет разрешения на обход каталога для достижения цели, но она не разорвана для пользователей с соответствующими привилегиями[
]. Резолюция: нет, ссылка не разорвана для всех.[ ]
[ - ]Ссылка используется для хранения информации, как в примере []Firefox lock, цитируемом vinc17[]. Одна из причин сделать это так - проще заполнить сим-ссылку атоматически - другого способа нет, в то время как заполнение файла атоматически сложнее: нужно создать содержимое файла под временным именем, затем переместить его на место, и обрабатывать просроченные временные файлы, оставленные после аварии. Другая причина заключается в том, что в некоторых файловых системах сим-ссылки, как правило, хранятся непосредственно внутри своего входа, что делает их чтение быстрее, чем чтение содержимого файла.[
]. Резолюция: нет. В этом случае удаление ссылки будет вредным.[ ]
[
]Если вы можете определить, что сим-ссылка попадает в первую категорию, то обязательно удалите ее. В противном случае воздержитесь.[
] []Программа, которая рекурсивно обходит каталоги и заботится о содержимом файлов, обычно должна игнорировать прерванные символические ссылки.[
].] Не удаляйте вслепую все висящие символические ссылки. Они могут существовать только для того, чтобы нести некоторую информацию, и могут быть более безопасными, чем обычные файлы, так как создание символических ссылок атомарно.[
] []Например, Firefox создает "замок", который представляет собой символическую ссылку, значение которой имеет форму "IP_address:+PID".[
].] Цитата из [] командной строки 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" есть ошибка (черт бы их побрал!), и нам нужно вернуться к старой версии. Опять же, мы просто удаляем символическую ссылку, указывающую на новую версию, и создаем новую символическую ссылку, указывающую на старую версию.[
] [
]Так что нет, я бы не стал удалять символические ссылки, так как это наверняка будет головной болью двигаться дальше, и вы рискуете серьезно испортить вашу систему.[
].Веб-сервер 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 был переименован в confirmation_file, по-прежнему является полезной информацией. Если вы зашли в каталог /etc и сделали ls и увидели, что файл с именем conf _ file отсутствует, но подтверждение _ file может быть достаточно информации для исправления ссылки.