Czy usunięcie wszystkich zepsutych dowiązań symbolicznych w systemie ma wadę?

Uruchomiłem skrypt, który iterował wszystkie pliki w moim systemie Linux i stworzyłem o nich metadane, i spowodował błąd, gdy trafił do zepsutego dowiązania symbolicznego.

Jestem nowicjuszem w * nix, ale mam główną ideę związaną z łączeniem plików i tym, jak powstają zepsute linki. O ile mi wiadomo, są one jak odpowiednik śmieci na ulicy. Rzeczy, które program, który usuwam, nie były wystarczająco inteligentne, aby stwierdzić, że menedżer pakietów istniał i do niego należał, lub coś, co pozostało w tyle podczas aktualizacji. Na początku zacząłem poprawiać skrypt, który uruchamiam, aby je pominąć, a potem pomyślałem: „no cóż, zawsze możemy je usunąć, gdy jesteśmy tutaj ...”

Używam Ubuntu 14.04 (Trusty Tahr). Nie widzę żadnego powodu, aby tego nie robić, ale zanim przejdę do tego i przejdę przez mój system programistyczny, czy istnieje jakikolwiek powód, że może to być okropny pomysł? Czy zepsute dowiązania symboliczne służą czemuś, o czym nie wiem?

Istnieje wiele przyczyn przerwania dowiązań symbolicznych:

• Utworzono link do celu, który już nie istnieje.
  Rozwiązanie: usuń zepsute dowiązanie symboliczne.
• Link został utworzony dla celu, który został przeniesiony. Lub jest to względny link, który został przeniesiony względem swojego celu. (Nie oznacza to, że względne dowiązania symboliczne są złym pomysłem - wręcz przeciwnie: absolutne dowiązania symboliczne są bardziej podatne na starzenie się, ponieważ ich cel został przeniesiony.)
  Rozwiązanie: znajdź zamierzony cel i napraw łącze.
• Podczas tworzenia linku wystąpił błąd.
  Rozwiązanie: znajdź zamierzony cel i napraw łącze.
• Łącze prowadzi do pliku znajdującego się na dysku wymiennym, sieciowym systemie plików lub innym obszarze pamięci, który nie jest aktualnie zamontowany. Rozdzielczość: brak, link nie jest cały czas zrywany. Łącze będzie działać, gdy obszar pamięci jest zamontowany.
• Link jest do pliku, który istnieje tylko przez pewien czas, zgodnie z projektem. Na przykład plik jest buforowanym wyjściem procesu, który jest usuwany, gdy informacje stają się nieaktualne, ale są tworzone ponownie na wyraźne żądanie. Lub link prowadzi do skrzynki odbiorczej, która jest usuwana, gdy jest pusta. Lub link prowadzi do pliku urządzenia, który jest obecny tylko wtedy, gdy podłączone jest odpowiednie urządzenie peryferyjne. Rozdzielczość: brak, link nie jest cały czas zrywany.
• Łącze jest prawidłowe tylko w innej hierarchii pamięci. Na przykład jest ważny tylko w więzieniu chroot lub jest eksportowany przez serwer NFS i jest ważny tylko na serwerze lub na niektórych jego klientach.
  Rozdzielczość: brak, link nie jest wszędzie uszkodzony.
• Link jest uszkodzony, ponieważ nie masz uprawnień do przeglądania katalogu, aby dotrzeć do celu, ale nie jest uszkodzony dla użytkowników z odpowiednimi uprawnieniami.
  Rozdzielczość: brak, link nie jest zepsuty dla wszystkich.
• Link służy do przechowywania informacji, jak w przykładzie blokady Firefoksa cytowanym przez vinc17 . Jednym z powodów, aby zrobić to w ten sposób, jest łatwiejsze atomowe wypełnienie dowiązania symbolicznego - nie ma innego sposobu, podczas gdy atomowe wypełnianie pliku jest bardziej złożone: musisz utworzyć zawartość pliku pod tymczasową nazwą, a następnie przenieść go na miejsce, i radzimy sobie z przestarzałymi plikami tymczasowymi pozostawionymi przez awarię. Innym powodem jest to, że dowiązania symboliczne są zwykle przechowywane bezpośrednio wewnątrz ich i-węzłów w niektórych systemach plików, co sprawia, że ​​czytanie ich jest szybsze niż czytanie zawartości pliku.
  Rozdzielczość: brak. W takim przypadku usunięcie linku byłoby szkodliwe.

Jeśli możesz ustalić, że dowiązanie symboliczne należy do pierwszej kategorii, to pewnie, śmiało i usuń je. W przeciwnym razie wstrzymaj się od głosu.

Program, który rekurencyjnie przegląda katalogi i dba o zawartość pliku, zwykle powinien ignorować zepsute dowiązania symboliczne.

Nie usuwaj na ślepo wszystkich wiszących dowiązań symbolicznych. Mogą istnieć tylko w celu przenoszenia niektórych informacji i mogą być bezpieczniejsze niż normalne pliki, ponieważ tworzenie dowiązań symbolicznych jest atomowe.

Na przykład Firefox tworzy plik blokady „blokada”, który jest dowiązaniem symbolicznym, którego wartość ma postać „Adres_IP: + PID”.

Zarówno fnord, jak i serwer Gatling używają systemu plików Unix jako bazy danych konfiguracji (w przeciwieństwie do, powiedzmy, Microsoft IIS, który korzysta z rejestru Windows, lub Apache, który używa pliku konfiguracyjnego złożonego do analizy).

Na przykład wirtualne hosty to tylko katalogi, a utworzenie nowego wirtualnego hosta jest tak proste, jak

mkdir www.example.com:80

Konfigurowanie plików do wyświetlenia?

chmod o+r file_that_should_be_served
chmod o-r secret_passwords

Konfigurowanie plików do wykonania jako CGI, a które do obsługi?

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

I na koniec (i dotyczy tego pytania): konfigurowanie przekierowania?

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

Otrzymasz teraz dowiązanie symboliczne, search.htmlktóre nigdzie nie wskazuje, ale ma to zasadnicze znaczenie dla działania Twojej witryny.

Dowiązanie symboliczne może wskazywać na jeszcze pustą lokalizację, aby wymusić utworzenie w określonej lokalizacji lub nazwie systemu plików.

Więc nie - nie usuwaj ich na ślepo.

Znaczącym minusem usuwania starych linków symbolicznych jest to, że tracisz odniesienie do miejsca, w którym kiedyś wskazywały, które mogą być bardzo cenne!

Powiedzmy, że mam dowiązanie symboliczne do pliku o nazwie „ send_to”, który wskazuje /Users/myname/tmpi przypuszczam, że /Users/myname/tmpnie istnieje.

Z linku symbolicznego wiem gdzie plik został przeznaczony być. Na przykład w tym przypadku widzę, że jest to katalog tymczasowy i jeśli muszę go „naprawić”, powinienem rozważyć katalog tymczasowy jako miejsce docelowe.

Podobnie link „ my_config”, /etc/conf_filektóry prowadzi do tego, że „źle”, ponieważ conf_filezmieniono jego nazwę na plik potwierdzenie_, nadal jest użyteczną informacją. Jeśli poszedłeś do /etckatalogu i zrobiłeś lsi zobaczyłeś, że conf_filebrakuje pliku o nazwie, ale confirmation_filemoże tam być wystarczająco dużo informacji, aby teraz naprawić link.

Cytowanie z wiersza poleceń systemu Linux (najlepsza książka dla początkujących użytkowników Linuksa, którą można pobrać bezpłatnie tutaj ):

Wyobraź sobie ten scenariusz: program wymaga użycia jakiegoś udostępnionego zasobu zawartego w pliku o nazwie „foo”, ale „foo” ma częste zmiany wersji. Dobrze byłoby dołączyć numer wersji do nazwy pliku, aby administrator lub inna zainteresowana strona mogła zobaczyć, która wersja „foo” jest zainstalowana. To stanowi problem. Jeśli zmienimy nazwę współdzielonego zasobu, musimy wyśledzić każdy program, który mógłby go użyć i zmienić go, aby szukać nowej nazwy zasobu za każdym razem, gdy instalowana jest nowa wersja zasobu. To wcale nie brzmi zabawnie.

Tutaj symboliczne linki ratują dzień. Załóżmy, że instalujemy wersję 2.6 „foo” o nazwie „foo-2.6”, a następnie tworzymy dowiązanie symboliczne zwane po prostu „foo”, które wskazuje na „foo-2.6”. Oznacza to, że gdy program otworzy plik „ foo ”, w rzeczywistości otwiera plik„ foo-2.6 ”. Teraz wszyscy są szczęśliwi. Programy oparte na „foo” mogą je znaleźć i nadal możemy zobaczyć, jaka wersja jest zainstalowana. Kiedy nadchodzi czas aktualizacji do „foo-2.7”, po prostu dodajemy plik do naszego systemu, usuwamy dowiązanie symboliczne „foo” i tworzymy nowy, który wskazuje na nową wersję. To nie tylko rozwiązuje problem aktualizacji wersji, ale także pozwala nam zachować obie wersje na naszym komputerze. Wyobraź sobie, że „foo-2.7” ma błąd (do cholery deweloperów!) I musimy wrócić do starej wersji. Jeszcze raz,

Więc nie, nie usuwałbym dowiązań symbolicznych, ponieważ z pewnością będzie to problem z bólem głowy, a ty ryzykujesz poważnym zepsuciem twojego systemu.