Чи є недолік видалення всіх порушених символьних посилань у системі?

У мене був запущений сценарій, який повторювався над усіма файлами моєї системи Linux і створив про них метадані, і він видав помилку, коли потрапив на розірване символічне посилання.

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

Я працюю на Ubuntu 14.04 (Trusty Tahr). Я не бачу жодної причини цього не робити, але, перш ніж продовжувати і запускати це над моєю системою розвитку, чи є якась причина, що це насправді може бути жахлива ідея? Чи зламані символьні посилання служать якійсь цілі, про яку я не знаю?

Є багато причин розриву символічних посилань:

• Було створено посилання на ціль, якої вже не існує.
  Розв’язання: видаліть розірване символьне посилання.
• Для цілі, яку було переміщено, було створено посилання. Або це відносне посилання, яке переміщене відносно його цілі. (Не маючи на увазі, що відносні символьні посилання є поганою ідеєю - зовсім навпаки: абсолютні символьні посилання більш схильні до того, що вони стають несвіжими, оскільки їх ціль перемістилася.)
  Розв’язання: знайти намічену ціль і виправити зв'язок.
• Під час створення посилання сталася помилка.
  Розв’язання: знайдіть цільову ціль і зафіксуйте посилання.
• Посилання - це файл, який знаходиться на знімному диску, мережевій файловій системі чи іншій області зберігання, яка наразі не встановлена. Дозвіл: жодне, посилання постійно не порушується. Посилання працює, коли змонтована область зберігання.
• Посилання - це файл, який існує лише деякий час, за задумом. Наприклад, файл - це кешований вихід процесу, який видаляється, коли інформація застаріла, але заново створюється за явним запитом. Або посилання на вхідні, які видаляються, коли порожні. Або посилання на файл пристрою, який присутній лише тоді, коли приєднана відповідна периферія. Дозвіл: жодне, посилання постійно не порушується.
• Посилання дійсне лише в іншій ієрархії зберігання. Наприклад, він дійсний лише у в'язниці chroot, або експортується сервером NFS і дійсний лише на сервері або на деяких його клієнтах.
  Дозвіл: жодне, посилання не повсюдно порушено.
• Посилання для вас порушено, оскільки вам не вистачає дозволу на проходження каталогу для досягнення цілі, але він не порушений для користувачів з відповідними привілеями.
  Дозвіл: жодне, посилання не перервано для всіх.
• Посилання використовується для зберігання інформації, як у прикладі блокування Firefox, цитованому vinc17 . Однією з причин зробити це так є те, що простіше заповнити символьне посилання атомним шляхом - іншого способу немає, тоді як заповнення файлу атомним чином є складнішим: потрібно створити вміст файлу під тимчасовим іменем, потім перемістити його на місце і обробляти застарілі тимчасові файли, залишені в результаті аварії. Інша причина полягає в тому, що символьні посилання, як правило, зберігаються безпосередньо в їхньому вході в деяких файлових системах, що робить їх читання швидшим, ніж читання вмісту файлу.
  Дозвіл: немає. У цьому випадку видалення посилання буде згубним.

Якщо ви можете визначити, що симпосилання попадає в першу категорію, тоді впевнено, ідіть і видаліть її. Інакше утримайтеся.

Програма, яка рекурсивно переходить до каталогів і піклується про вміст файлу, зазвичай ігнорує розірвані символічні посилання.

Не слід сліпо видаляти всі звисаючі символічні посилання. Вони можуть існувати лише для того, щоб нести певну інформацію, і можуть бути безпечнішими, ніж звичайні файли, оскільки створення символьної посилання є атомним.

Наприклад, Firefox створює файл замка "замок", який є символьним посиланням, значення якого має форму типу "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перейменований на файл підтвердження все ще корисна інформація. Якщо ви зайшли в /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" має помилку (чорт за розробниками!), І нам потрібно повернутися до старої версії. Знову ж таки,

Так що ні, я б не видаляв символічні посилання, оскільки це, безумовно, буде боліти головою, і ви ризикуєте серйозно зіпсувати свою систему.