Dlaczego dowiązania twarde do katalogów są niedozwolone w systemie UNIX / Linux?

To po prostu zły pomysł, ponieważ nie jest sposobem na odróżnienie twardego odsyłacza od oryginalnej nazwy.

Zezwolenie na twarde linki do katalogów złamałoby ukierunkowaną acykliczną strukturę grafu systemu plików, prawdopodobnie tworząc pętle katalogów i wiszące poddrzewa katalogów, co sprawić, by fsck i wszelkie inne programy spacerujące po drzewie plików były podatne na błędy.

Najpierw, aby to zrozumieć, porozmawiajmy o i-węzłach. Dane w systemie plików są przechowywane w bloki na dysku, a te bloki są zbierane razem przez i-węzeł. Możesz myśleć o i-węźle jako o pliku. I-węzły nie mają jednak nazw plików. To tutaj pojawiają się linki.

Łącze to po prostu wskaźnik do i-węzła. Katalog to i-węzeł przechowujący łącza. Każda nazwa pliku w katalogu to tylko łącze do i-węzła. Otwarcie pliku w Uniksie również tworzy łącze, ale jest to łącze innego typu (nie jest to łącze nazwane).

Twardy link to po prostu dodatkowy wpis katalogu wskazujący na ten i-węzeł. Gdy ls -l, liczba po uprawnieniach to nazwana liczba linków. Większość zwykłych plików ma jedno łącze. Utworzenie nowego twardego łącza do pliku spowoduje, że obie nazwy plików będą wskazywały ten sam i-węzeł. Uwaga:

% ls -l test ls: test: No such file or directory % touch test % ls -l test -rw-r--r-- 1 danny staff 0 Oct 13 17:58 test % ln test test2 % ls -l test* -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 % touch test3 % ls -l test* -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 -rw-r--r-- 1 danny staff 0 Oct 13 17:59 test3 ^ ^ this is the link count 

Teraz możesz wyraźnie zobaczyć, że nie ma czegoś takiego jak twardy link. Twardy link to to samo, co zwykła nazwa. W powyższym przykładzie test lub test2, który jest oryginalnym plikiem, a który twardym łączem? Na koniec nie można tego powiedzieć (nawet na podstawie sygnatur czasowych), ponieważ obie nazwy wskazują na tę samą zawartość, ten sam i-węzeł:

% ls -li test* 14445750 -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test 14445750 -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 14445892 -rw-r--r-- 1 danny staff 0 Oct 13 17:59 test3 

-i do ls pokazuje numery i-węzłów na początku wiersza. Zwróć uwagę, jak test i test2 mają ten sam numer i-węzła, ale test3 ma inny.

Teraz, gdybyś mógł zrób to dla katalogów, dwa różne katalogi w różnych punktach systemu plików mogą wskazywać na tę samą rzecz. W rzeczywistości podkatalog może wskazywać z powrotem na swojego dziadka, tworząc pętlę.

Dlaczego ta pętla jest niepokojąca ? Ponieważ podczas przemierzania nie ma sposobu, aby wykryć, że wykonujesz pętlę (bez śledzenia numerów i-węzłów podczas przechodzenia). Wyobraź sobie, że piszesz polecenie du, które musi powtarzać w podkatalogach, aby dowiedzieć się o wykorzystaniu dysku. Skąd du wiedzieć, czy n uderzył w pętlę? Jest podatny na błędy i wymaga wielu czynności księgowych, które du musiałoby wykonać, aby wykonać to proste zadanie.

Dowiązania symboliczne to zupełnie inna bestia w że są one specjalnym typem „pliku”, za którym automatycznie podąża wiele funkcji API systemu plików. Zauważ, że łącze symboliczne może wskazywać na nieistniejące miejsce docelowe, ponieważ wskazują one według nazwy, a nie bezpośrednio do i-węzła. Ta koncepcja nie ma sensu w przypadku twardych linków, ponieważ samo istnienie „twardego linku” oznacza, że plik istnieje.

Dlaczego więc du poradzi sobie z dowiązania symboliczne są łatwe, a nie twarde? Widzieliśmy powyżej, że twarde łącza są nie do odróżnienia od zwykłych wpisów w katalogu. Jednak łącza symboliczne są specjalne, wykrywalne i możliwe do pominięcia! du zauważa, że łącze symboliczne to łącze symboliczne, które całkowicie je pomija!

% ls -l total 4 drwxr-xr-x 3 danny staff 102 Oct 13 18:14 test1/ lrwxr-xr-x 1 danny staff 5 Oct 13 18:13 test2@ -> test1 % du -ah 242M ./test1/bigfile 242M ./test1 4.0K ./test2 242M . 

Komentarze

• Allowing hard links to directories would break the directed acyclic graph structure of the filesystem.Czy możesz wyjaśnić więcej o problemie z cyklami używającymi twardych linków? Dlaczego jest to w porządku z dowiązaniami symbolicznymi
• Wydaje się, że zezwolili na to na komputerach Mac dodając wykrywanie cyklu do wywołania systemowego link () i odmawiając pozwolenia na utworzenie dowiązania do katalogu, jeśli miałoby to stworzyć cykl . Wydaje się, że jest to rozsądne rozwiązanie.
• @psusi mkdir -p a / b; nocheckln c a; mv c a / b; – w nocheckln istnieje teoretyczny ln, który nie sprawdza argumentów katalogu i po prostu przechodzi do linku, a ponieważ nie ma cyklu, wszyscy jesteśmy dobrzy w tworzeniu ' c '. następnie przenosimy ' c ' do ' a / b ', a cykl jest tworzony z a / b / c – > a / – sprawdzanie linku () nie jest wystarczająco dobre
• Cykle są bardzo złe. System Windows ma ten problem z ” połączeniami „, które są katalogami z dowiązaniami twardymi. Jeśli przypadkowo zastosujesz uprawnienia do całego profilu, odkryje on szereg skrzyżowań, które tworzą nieskończony cykl. Cykliczne przechodzenie przez katalogi powtarza się, dopóki ograniczenia długości ścieżki nie zatrzymają go.
• @WhiteWinterWolf, zgodnie z tym linkiem, specjalnie dodali obsługę tego wehikułu czasu, ale tylko root może to zrobić: superuser.com/questions/360926/…

Możesz użyć bind mount do symulacji twardych linków do katalogów

sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory sudo umount /else/dummy_but_existing_directory 

Z wyjątkiem punktów podłączenia, każdy katalog ma jednego i jedynego nadrzędnego: ...

Jeden sposób pwd to sprawdzenie urządzenia: i-węzła dla „.” i „..”. Jeśli są takie same, dotarłeś do katalogu głównego systemu plików. W przeciwnym razie znajdź nazwę bieżącego katalogu w katalogu nadrzędnym, umieść ją na stosie i zacznij porównywać „../”. z „../ ..”, a następnie „../../”. z „../../ ..” itd. Kiedy już trafisz do katalogu głównego, zacznij wyświetlać i wypisywać nazwy ze stosu. Algorytm ten opiera się na fakcie, że każdy katalog ma jednego i tylko jednego rodzica.

Jeśli dozwolone były twarde linki do katalogów, na który jeden z wielu elementów nadrzędnych .. powinien wskazywać? To jeden z istotnych powodów, dla których twarde linki do katalogów są niedozwolone.

Dowiązania symboliczne do katalogów nie powodują tego problemu. Jeśli program chce, może wykonać lstat() na każdej części ścieżki i wykryć, kiedy napotkano dowiązanie symboliczne. Algorytm pwd zwróci prawdziwą bezwzględną ścieżkę do katalogu docelowego. Fakt, że gdzieś znajduje się fragment tekstu (dowiązanie symboliczne), który wskazuje na katalog docelowy, jest właściwie nieistotny. Istnienie takiego linku symbolicznego nie tworzy pętli na wykresie.

Komentarze

• Nie jestem tego pewien. Jeśli pomyślimy o .. jako o rodzaju wirtualnego dowiązania do elementu nadrzędnego, nie ma żadnego technicznego powodu, by cel łącza mógł mieć tylko jedno inne łącze. pwd musiałby po prostu użyć innego algorytmu do rozwiązania ścieżki.

Chciałbym dodać jeszcze kilka uwag dotyczących tego pytania. Twarde linki do katalogów są dozwolone w Linuksie, ale w ograniczony sposób.

Jednym ze sposobów, w jaki możemy to sprawdzić, jest pokazanie zawartości katalogu, w którym znajdziemy dwa specjalne katalogi „.” i „..”. Jak wiemy „.” wskazuje na ten sam katalog, a „..” wskazuje na katalog nadrzędny.

Stwórzmy więc drzewo katalogów, gdzie „a” jest katalogiem nadrzędnym, który ma katalog „b” jako potomek.

 a `-- b 

Zanotuj i-węzeł katalogu „a”. A kiedy wykonamy ls -la z katalogu „a”, zobaczymy to „.” katalog wskazuje również na ten sam i-węzeł.

797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 a 

I tutaj możemy znaleźć, że katalog „a” ma trzy dowiązania stałe. Dzieje się tak, ponieważ i-węzeł 797358 ma trzy dowiązania stałe w nazwie „”. w katalogu „a” i nazwie „..” w katalogu „b” i w katalogu o nazwie „a” itslef.

$ ls -ali a/ 797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 . $ ls -ali a/b/ 797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 .. 

Tutaj możemy zrozumieć że dowiązania twarde są dostępne tylko dla katalogów, aby łączyć się z ich katalogami nadrzędnymi i podrzędnymi. Tak więc katalog bez elementu potomnego będzie miał tylko 2 dowiązania twarde, a więc katalog „b” będzie miał tylko dwa dowiązania twarde.

Jednym z powodów, dla których swobodne dowiązanie twarde katalogów zostało uniemożliwione, byłoby uniknięcie nieskończonych pętli odwołań, które zmyli programy, które przemierzają system plików.

Ponieważ system plików jest zorganizowany w postaci drzewa, a drzewo nie może mieć cyklicznych odwołań, należy tego unikać.

Komentarze

• Dobry przykład. To rozwiało moje wątpliwości. Dlatego te przypadki są obsługiwane w specjalny sposób, aby uniknąć nieskończonych pętli. dobrze?
• Ponieważ mamy ograniczony sposób zezwalania na twarde linki do katalogów, np. ” .. ” i „. ” nie osiągniemy nieskończonej pętli, więc nie będziemy potrzebować żadnych specjalnych sposobów, aby ich uniknąć, ponieważ nie będą się one zdarzać 🙂

Żadne z poniższych nie jest prawdziwym powodem zablokowania twardych linków do katalogów; każdy problem jest dość łatwy do rozwiązania:

• cykle w strukturze drzewa powodują trudne przechodzenie
• wielu rodziców, więc który z nich jest „prawdziwy”?
• usuwanie elementów bezużytecznych w systemie plików

prawdziwy powód (zgodnie z sugestią @ Thorbjørn Ravn Andersen) pojawia się, gdy usuniesz katalog, który ma wielu rodziców, z katalogu wskazanego przez ..:

Na co .. powinno teraz wskazywać?

Jeśli katalog zostanie usunięty z jego nadrzędnego, ale liczba linków jest nadal większe niż 0, to musi być coś, gdzieś wciąż na to wskazuje. Nie możesz „t zostawić .. wskazujących na nic; wiele programów polega na .., więc system musiałby przejść przez cały system plików , dopóki nie znajdzie pierwszej rzeczy wskazującej na usunięty katalog, aby zaktualizować ... Albo to, albo system plików będzie musiał utrzymywać listę wszystkie katalogi wskazują na trwale połączony katalog.

Tak czy inaczej, byłby to narzut i dodatkowe komplikacje dla metadanych i / lub kodu systemu plików, więc projektanci zdecydowali się na to nie zezwalać.

Komentarze

• To ' jest również łatwe do rozwiązania: prowadź listę nadrzędnych katalogu podrzędnego, które aktualizujesz po dodaniu lub usunięciu linku do dziecka. Gdy usuniesz kanonicznego rodzica (cel dziecka ' s

  ), zaktualizuj .., aby wskazywał na jednego z pozostałych rodziców na liście.

• Zgadzam się. Nie fizyka jądrowa do rozwiązania. Niemniej jednak powoduje to obciążenie wydajnościowe i zajęłoby trochę więcej miejsca w metadanych systemu plików i spowodowałoby komplikacje. Dlatego projektanci zdecydowali się na proste, szybkie podejście – nie ' nie zezwalaj na linki do twardych katalogów.
• Symowe linki do katalogów ” naruszają ustaloną semantykę i zachowania „, ale nadal są dozwolone. Dlatego niektóre polecenia wymagają opcji kontrolujących, czy są stosowane dowiązania symboliczne (np. -L w find i cp). Gdy program podąża za ' .. ' następuje dalsze zamieszanie, stąd różnica w wynikach z pwd i / bin / pwd po przejściu przez łącze sym. Nie ma ” odpowiedzi Unixa „; tylko decyzje projektowe. Ta obraca się wokół tego, co stanie się z ” .. „, jak napisałem w mojej odpowiedzi. Niestety, ' .. ' nie ' nie wspomniał nawet w odpowiedzi, że wszyscy inni głosuje tak nieśmiało.
• Przy okazji, ' nie mówię, że ' wolę twarde linki do reż. Ani trochę. Nie ' nie chcę, aby moja codzienna praca była trudniejsza niż jest.
• To ' to nie wszystko POSIX mówi, ale IMO ' .. ' nigdy nie powinno być koncepcją systemu plików, raczej rozwiązaną składniowo na ścieżkach, więc a/.. zawsze oznaczałoby .. Tak przy okazji działają adresy URL. To ' to przeglądarka, która ' rozwiązuje ' .. ' zanim jeszcze trafi na serwer. I działa świetnie.

Tworzenie twardych linków w katalogach byłoby nieodwracalne. Załóżmy, że mamy:

/dir1 ├──this.txt ├──directory │ └──subfiles └──etc 

Na stałe powiązuję go z /dir2.

Więc /dir2 zawiera teraz również wszystkie te pliki i katalogi

A jeśli zmienię zdanie? Nie mogę po prostu „t rmdir /dir2 (ponieważ nie jest pusty)

A jeśli rekurencyjnie usuwam w /dir2. .. zostanie również usunięty z /dir1!

IMHO to jest w dużej mierze wystarczający powód, aby tego uniknąć!

Edycja:

Komentarze sugerują usunięcie katalogu przez wykonanie rm na nim .Ale rm na niepustym katalogu kończy się niepowodzeniem i to zachowanie musi pozostać, niezależnie od tego, czy katalog jest połączony czy nie. Możesz więc po prostu „t rm odłączyć. Wymagałoby to nowego argumentu do rm, żeby powiedzieć tylko, że„ jeśli i-węzeł katalogu ma liczbę odwołań> 1, a następnie odłącz tylko katalog ”.

Co z kolei łamie kolejną zasadę najmniejszego zaskoczenia: oznacza to, że usunięcie utworzonego właśnie przeze mnie dowiązania do katalogu nie jest tym samym, co usunięcie zwykłego dowiązania do pliku …

Przeformułuję moje zdanie: bez dalszego rozwoju tworzenie dowiązania twardego byłoby nieodwracalne (ponieważ żadne aktualne polecenie nie mogłoby obsłużyć usunięcia bez bycia niespójnym z obecnym zachowaniem)

Jeśli pozwolimy na więcej prac rozwojowych, aby zająć się tą sprawą, liczba pułapek i ryzyko utraty danych , jeśli „nie są wystarczająco świadomi tego, jak działa system, sugeruje taki rozwój, czy IMHO jest wystarczającym powodem do ograniczenia twardych linków w katalogach.

Komentarze

• To nie powinno stanowić problemu. W twoim przypadku, kiedy tworzymy hardlink do dir2, musimy stworzyć hardlink do całej zawartości w dir1, więc jeśli zmienimy nazwę lub usuniemy dir2, tylko dodatkowy link do i-węzła zostanie usunięty. I to nie powinno mieć wpływu na katalog dir1 i jego zawartość, ponieważ istnieje przynajmniej jedno łącze (dir1) do i-węzła.
• Twój argument jest nieprawidłowy. Po prostu odłączysz go, a nie rm -rf. A jeśli liczba linków osiągnie 0, system będzie wiedział, że może również usunąć całą zawartość.
• To ' to mniej więcej wszystkie i tak działa poniżej (odłącz). Zobacz: unix.stackexchange.com/questions/151951/… To naprawdę nie jest ' to problem, podobnie jak w przypadku plików dowiązanych na stałe. Odłączenie po prostu usuwa nazwane odwołanie i zmniejsza liczbę łączy. Fakt, że rmdir wygrał ' nie usuwając niepustych katalogów, jest nieistotny – nie ' nie rób tego również dla dir1. Twarde łącza nie są ' kopiami danych, są to ten sam rzeczywisty plik, stąd w rzeczywistości ” usuwanie ” plik dir2 wymazałby listę katalogów dla dir1. Zawsze trzeba by odłączyć.
• Możesz ' po prostu odłączyć go jak zwykły plik, ponieważ rm w katalogu nie ' t odłącz go, jeśli ' nie jest pusty. Zobacz Edytuj.

To dobre wyjaśnienie. Jeśli chodzi o pytanie „Który z rodziców z dwojga rodziców powinien .. wskazać?” jednym rozwiązaniem byłoby utrzymywanie przez proces pełnej ścieżki wd, jako i-węzłów lub jako łańcuch. i-węzły byłyby bardziej niezawodne, ponieważ nazwy można zmieniać. Przynajmniej w dawnych czasach istniał wewnętrzny i-węzeł dla każdego otwartego pliku, który był zwiększany przy każdym otwarciu pliku, a zmniejszany po zamknięciu. Kiedy osiągnie zero, magazyn, który wskazywał, zostanie uwolniony. Gdy plik nie był już przez nikogo otwarty, (kopia w rdzeniu) zostanie porzucony. Dzięki temu ścieżka byłaby prawidłowa, gdyby jakiś inny proces przeniósł katalog do innego katalogu, podczas gdy podkatalog znajdował się na ścieżce innego procesu. Podobnie jak można usunąć otwarty plik, ale jest on po prostu usuwany z katalogu, ale nadal jest otwarty dla wszystkich procesów, które go otworzyły.

Twarde łączenie katalogów było kiedyś swobodnie dozwolone w Bell Labs UNIX, przynajmniej V6 i V7, Nie wiem o Berkeley lub późniejszym. Nie jest wymagana flaga. Czy mógłbyś tworzyć pętle? Tak, nie rób tego. Jeśli zrobisz pętlę, jest bardzo jasne, co robisz. Nether powinien ćwiczyć wiązanie węzłów na szyi, czekając na swoją kolej do wyskoczenia z samolotu, jeśli drugi koniec jest wygodnie zawieszony na haku na głowicy.

Co Miałem nadzieję, że zrobię z tym dzisiaj połączenie na stałe z domem do domu, tak żebym mógł mieć dostęp do katalogu / home / administ niezależnie od tego, czy / home byłby zasłonięty automatycznym podłączeniem do domu, a to automount miało łącze symboliczne o nazwie administ do / lhome / administ. Dzięki temu mogę mieć konto administracyjne, które działa niezależnie od stanu mojego podstawowego domowego systemu plików. To JEST eksperymentem dla Linuksa, ale myślę, że kiedyś nauczyłem się dla SunOS opartego na UCB, że automatyczne montowanie odbywa się na poziomie łańcucha ascii. Trudno sobie wyobrazić, jak można by to zrobić inaczej jako warstwę na dowolnym dowolnym FS.

Czytałem o tym gdzie indziej. i .. również nie są już plikami w katalogu. Jestem pewien, że są ku temu dobre powody i że wiele z tego, co lubimy (na przykład możliwość montowania NTFS) jest możliwe dzięki takim rzeczom, ale część elegancji UNIX była w implementacji.To właśnie takie korzyści, jak ogólność i plastyczność, które zapewnia ta elegancja, pozwoliły mu być tak solidnym i wytrzymać przez cztery dekady. Kiedy tracimy eleganckie implementacje, w końcu stanie się jak Windows (mam nadzieję, że się mylę!). Ktoś wtedy stworzyłby nowy system operacyjny oparty na eleganckich zasadach. Coś do przemyślenia. Być może się mylę, nie znam (oczywiście) obecnej implementacji. To jest niesamowite, chociaż 30-letnie zrozumienie ma zastosowanie do Linuksa … przez większość czasu!

Komentarze

• Myślę, chociaż mogę się mylić, że . i .. nie są twardymi dowiązaniami w systemie plików dla nowoczesnych systemów plików. Jednak sterownik systemu plików je fałszuje. To właśnie te systemy plików zatrzymują katalogi z linkami twardymi. W przypadku starych systemów plików było to możliwe (ale niebezpieczne). Aby zrobić to, co próbujesz, spójrz na mount --bind, zobacz także mount --make… i być może kontenery.

Z tego, co wiem, głównym powodem jest to, że warto mieć możliwość zmiany nazw katalogów bez zakłócania działania programów, które używają ich katalog roboczy, aby odnieść się do innych plików. Załóżmy, że używasz Wine do uruchomienia ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe i chcesz zamiast tego przenieść cały prefiks do ~/.wine. Jeśli z jakiegoś dziwnego powodu Firefox uzyskiwał dostęp do drive_c/windows, odwołując się do ../../windows, zmieniając nazwę ~/.newwineprefix przerw implementacje .., które śledzą katalog nadrzędny jako ciąg tekstowy zamiast i-węzła.

Przechowywanie i-węzła pojedynczego katalogu nadrzędnego musi być prostsze niż próbowanie aby śledzić każdą ścieżkę zarówno jako ciąg tekstowy, jak i serię i-węzłów.

Innym powodem jest to, że niewłaściwe zachowanie aplikacje mogą tworzyć pętle. Zachowujące się aplikacje powinny być w stanie sprawdzić, czy i-węzeł katalogu, który jest przenoszony, jest taki sam jak i-węzeł dowolnego z zagnieżdżonych katalogów, do którego jest przenoszony, tak jak nie można przenieść katalogu do siebie samego, ale to może nie być wymuszone na poziomie systemu plików.

Jeszcze innym powodem może być to, że gdybyś mógł dowiązać do katalogów twardym dowiązaniem, chciałbyś zapobiec dowiązaniu do katalogu, którego nie możesz zmodyfikować. find ma względy bezpieczeństwa, ponieważ jest używany do usuwania plików utworzonych przez innych użytkowników z katalogów tymczasowych, co może powodować problemy, jeśli użytkownik przełączy prawdziwy katalog na łącze symboliczne, podczas gdy find wywołuje inne polecenie. Możliwość bezpośredniego dowiązania ważnych katalogów zmusiłaby administratora do dodania dodatkowych testów do find, aby nie wpływać na nie. (Ok, już nie można tego zrobić dla plików, więc ten powód jest nieprawidłowy.)

Jeszcze innym powodem jest to, że przechowywanie i-węzła katalogu nadrzędnego może zapewnić dodatkową nadmiarowość w przypadku uszkodzenia lub uszkodzenia systemu plików. chciałem, aby .. zawierał listę wszystkich katalogów nadrzędnych, które są połączone na stałe z tym, aby można było łatwo znaleźć inny, arbitralny element nadrzędny, jeśli bieżący jest oddzielony, nie tylko naruszasz ten pomysł łącza są równe, musisz zmienić sposób, w jaki system plików przechowuje i używa i-węzłów. Programy traktują ścieżki jako serie (unikalne ue do każdego hardlink) i-węzłów katalogów pozwoliłoby uniknąć tego, ale nie uzyskałbyś nadmiarowości w przypadku uszkodzenia systemu plików.