Dlaczego twarde linki do katalogów nie są dozwolone w UNIX / Linux?

W podręcznikach czytałem, że Unix / Linux nie dopuszcza twardych linków do katalogów, ale dopuszcza miękkie linki. Czy to dlatego, że kiedy mamy cykle i jeśli tworzymy twarde linki, a po pewnym czasie usuwamy oryginalny plik, wskaże on jakąś wartość śmieci?

Jeśli cykle były jedynym powodem, dla którego nie zezwalano na twarde linki, to dlaczego dozwolone są miękkie linki do katalogów?

To po prostu zły pomysł, ponieważ nie ma sposobu na odróżnienie twardego linku od oryginalnej nazwy.

Dopuszczenie twardych linków do katalogów złamałoby ukierunkowaną acykliczną strukturę graficzną systemu plików, prawdopodobnie tworząc pętle katalogów i zawieszające się poddrzewa katalogów, co spowodowałoby fsckbłędy i wszelkie inne metody przechodzenia przez drzewa plików.

Po pierwsze, aby to zrozumieć, porozmawiajmy o i-węzłach. Dane w systemie plików są przechowywane w blokach na dysku, a te bloki są gromadzone razem przez i-węzeł. Możesz uważać i-węzeł za plik. Jednak w i-węzłach brakuje nazw plików. Tam właśnie wchodzą linki.

Link jest tylko wskaźnikiem do i-węzła. Katalog to i-węzeł, który zawiera łącza. Każda nazwa pliku w katalogu jest tylko linkiem do i-węzła. Otwarcie pliku w Uniksie również tworzy łącze, ale jest to inny typ łącza (nie jest to łącze nazwane).

Twardy link to tylko dodatkowy wpis katalogu wskazujący na ten i-węzeł. Kiedy ty ls -l, liczba po uprawnieniach to podana liczba linków. Większość zwykłych plików będzie miała jeden link. Utworzenie nowego twardego łącza do pliku spowoduje, że obie nazwy plików wskażą 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 wyraźnie widać, że nie ma czegoś takiego jak twarde łącze. Twardy link jest taki sam jak zwykła nazwa. W powyższym przykładzie testlub test2, który jest oryginalnym plikiem, a który jest twardym łączem? Do końca nie można tak naprawdę powiedzieć (nawet według znaczników czasu), ponieważ obie nazwy wskazują na tę samą treść, 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

-iFlagę lspokazuje-węzła numery na początku wiersza. Zwróć uwagę, jak testi test2mają ten sam numer i-węzła, ale test3ma inny.

Teraz, jeśli pozwolono ci to zrobić dla katalogów, dwa różne katalogi w różnych punktach systemu plików mogłyby wskazywać na to samo. W rzeczywistości podkatalog może wskazywać na dziadka, tworząc pętlę.

Dlaczego ta pętla jest problemem? Ponieważ podczas przemierzania nie ma możliwości wykrycia pętli (bez śledzenia numerów i-węzłów podczas przechodzenia). Wyobraź sobie, że piszesz dupolecenie, które musi się powtarzać w podkatalogach, aby dowiedzieć się o użyciu dysku. Skąd miałby duwiedzieć, kiedy uderzy w pętlę? Jest podatny na błędy i wiele księgowości dumusiałoby zrobić, aby wykonać to proste zadanie.

Dowiązania symboliczne to zupełnie inna bestia, ponieważ są specjalnym typem „pliku”, do którego wiele interfejsów API systemu plików zwykle stosuje się automatycznie. Uwaga: dowiązanie symboliczne może wskazywać na nieistniejące miejsce docelowe, ponieważ wskazują one według nazwy, a nie bezpośrednio na i-węzeł. Ta koncepcja nie ma sensu w przypadku twardych linków, ponieważ samo istnienie „twardego linku” oznacza, że ​​plik istnieje.

Dlaczego więc łatwo duradzić sobie z linkami symbolicznymi, a nie twardymi? Widzieliśmy powyżej, że twardych linków nie można odróżnić od zwykłych pozycji katalogu. Dowiązania symboliczne są jednak specjalne, wykrywalne i możliwe do pominięcia!  duzauważa, że ​​dowiązanie symboliczne jest dowiązaniem symbolicznym i 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    .

Z wyjątkiem punktów montowania, każdy katalog ma jedynego rodzica: ...

Jednym ze sposobów pwdjest sprawdzenie urządzenia: i-węzeł dla „.” i '..'. Jeśli są takie same, osiągnąłeś katalog główny systemu plików. W przeciwnym razie znajdź nazwę bieżącego katalogu nadrzędnego, pchnij ją na stos i zacznij porównywać „../”. z „../ ..”, a następnie „../../.” za pomocą „../../ ..” itp. Po uderzeniu w root, zacznij wyskakiwać i drukować nazwy ze stosu. Algorytm ten polega na tym, że każdy katalog ma jednego i tylko jednego rodzica.

Jeśli dozwolone byłyby twarde linki do katalogów, na które z wielu rodziców należy ..wskazać? Jest to jeden z istotnych powodów, dla których nie można wprowadzać twardych linków do katalogów.

Dowiązania symboliczne do katalogów nie powodują tego problemu. Jeśli program tego chce, może wykonać lstat()na każdej części nazwy ścieżki i wykryć, kiedy napotkane zostanie dowiązanie symboliczne. pwdAlgorytm powróci prawdziwą bezwzględną ścieżkę do katalogu docelowego. Fakt, że gdzieś jest kawałek tekstu (dowiązanie symboliczne), który wskazuje na katalog docelowy, jest praktycznie nieistotny. Istnienie takiego dowiązania symbolicznego nie tworzy pętli na wykresie.

Możesz użyć bind mount do symulacji katalogów z twardym łączeniem

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

Chciałbym dodać jeszcze kilka punktów na temat tego pytania. Twarde linki do katalogów są dozwolone w systemie Linux, ale w ograniczony sposób.

Jednym ze sposobów, w jaki możemy to przetestować, jest umieszczenie na liście zawartości katalogu dwóch specjalnych katalogów „”. i "..". Jak wiemy "." wskazuje na ten sam katalog, a „..” wskazuje na katalog nadrzędny.

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

 a
 `-- b

Zanotuj i-węzeł katalogu „a”. A kiedy robimy ls -laz katalogu „a”, możemy to zobaczyć ”. 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 stwierdzić, że katalog „a” ma trzy twarde linki. Jest tak, ponieważ i-węzeł 797358 ma trzy dowiązania twarde w nazwie „.” w katalogu „a” i nazwie jako „..” w katalogu „b” i jednej o nazwie „a”.

$ 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 ..

W tym miejscu możemy zrozumieć, że twarde linki są dostępne tylko dla katalogów łączących się z katalogami nadrzędnymi i podrzędnymi. I tak katalog bez dziecka będzie miał tylko 2 hardlink, a więc katalog „b” będzie miał tylko dwa hardlink.

Jednym z powodów, dla których udaremniono swobodne łączenie katalogów, byłoby unikanie nieskończonych pętli referencyjnych, które dezorientowałyby programy przechodzące przez system plików.

Ponieważ system plików jest zorganizowany jako drzewo i ponieważ drzewo nie może mieć cyklicznego odniesienia, należy tego unikać.

Żadne z poniższych nie są prawdziwym powodem do odrzucenia 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 jest „prawdziwy”?
• odśmiecanie systemu plików

Prawdziwy powód (jak zasugerował przez @ Thorbjørn Ravn Andersen) pochodzi kiedy usunąć katalog, który ma wielu rodziców, z katalogu wskazywanego przez ..:

Co powinno ..teraz wskazywać?

Jeśli katalog zostanie usunięty z jego obiektu nadrzędnego, ale liczba jego linków jest nadal większa niż 0wtedy, musi być coś, gdzieś nadal wskazuje na to. Nie możesz odejść, ..wskazując na nic; wiele programów polega na tym .., więc system musiałby przeglądać cały system plików, dopóki nie znajdzie pierwszej rzeczy, która wskazuje na usunięty katalog, tylko do aktualizacji ... Albo to, albo system plików musiałby utrzymywać listę wszystkich katalogów wskazujących na twardy link do katalogu.

Tak czy inaczej, byłby to narzut wydajnościowy i dodatkowa komplikacja dla metadanych i / lub kodu systemu plików, więc projektanci postanowili na to nie zezwalać.

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

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

Hardlink to do /dir2.

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

Co jeśli zmienię zdanie? Nie mogę tak po prostu rmdir /dir2(bo nie jest pusty)

A jeśli rekursywnie usunę w /dir2... zostanie również usunięty /dir1!

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

Edytować :

Komentarze sugerują usunięcie katalogu, wykonując rmna nim. Ale rmw niepustym katalogu zawodzi i to zachowanie musi pozostać, niezależnie od tego, czy katalog jest połączony na stałe, czy nie. Więc nie możesz tego po prostu rmrozłączyć. Wymagałoby to nowego argumentu rm, aby powiedzieć „jeśli i-węzeł katalogu ma liczbę odwołań> 1, wówczas tylko rozłącz katalog”.

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

Przeformułuję zdanie: Bez dalszego rozwoju tworzenie linku trwałego byłoby nieodwracalne (ponieważ żadne bieżące polecenie nie poradziłoby sobie z usunięciem bez niespójności z bieżącym zachowaniem)

Jeśli pozwolimy na dalszy rozwój, aby poradzić sobie ze sprawą, liczba pułapek i ryzyko utraty danych, jeśli nie będziesz wystarczająco świadomy działania systemu, oznacza to, że taki rozwój jest wystarczającym powodem do ograniczenia twardego linkowania do katalogów.

To dobre wytłumaczenie. Odnośnie do „Które z wielu rodziców powinno… wskazać?” jednym rozwiązaniem byłoby zachowanie przez proces pełnej ścieżki wd, jako i-węzłów lub łańcucha. 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. Gdy osiągnie zero, pamięć, którą wskazywał, zostanie zwolniona. Gdy plik nie był już przez nikogo otwarty, zostanie on (The-core-copy) porzucony. Utrzymałoby to prawidłową ścieżkę, jeśli jakiś inny proces przeniósł katalog do innego katalogu, podczas gdy podkatalog znajdował się na ścieżce innego procesu. Podobnie jak w przypadku usuwania otwartego pliku, ale jest on po prostu usuwany z katalogu,

Twarde linki do katalogów były swobodnie dozwolone w Bell Labs UNIX, przynajmniej V6 i V7, Nie wiem o Berkeley lub później. Flaga nie jest wymagana. Czy możesz zrobić pętle? Tak, nie rób tego. Jest bardzo jasne, co robisz, jeśli robisz pętlę. Nether powinieneś ćwiczyć wiązanie węzłów na szyi, gdy czekasz na swoją kolej, aby skoczyć z samolotu, jeśli drugi koniec jest wygodnie zawieszony na haku na masie.

To , co chciałem dzisiaj z tym zrobić, to połączenie na stałe lhome z domem, abym mógł mieć dostęp do / home / administ bez względu na to, czy / home był przykryty automatem nad domem, czy to automount posiadający dowiązanie symboliczne administ do / lhome / administ. Umożliwia mi to posiadanie konta administracyjnego, które działa niezależnie od stanu mojego podstawowego systemu plików domowych. To jest eksperyment dla Linuksa, ale myślę, że kiedyś dowiedziałem się dla SunOS opartego na UCB, że automounty są wykonywane na poziomie łańcucha ascii. Trudno zobaczyć, jak można by to zrobić inaczej, jako warstwę na dowolnym dowolnym FS.

Czytałem gdzie indziej. i .. nie są już plikami w katalogu. Jestem pewien, że istnieją ku temu dobre powody i że wiele z tego, co lubimy (np. Możliwość zamontowania NTFS) jest możliwe z powodu takich rzeczy, ale niektóre z elegancji UNIX były we wdrażaniu. Dzięki takim zaletom, jak ogólność i plastyczność, ta elegancja zapewniła jej wytrzymałość i wytrzymałość przez cztery dekady. Gdy tracimy eleganckie implementacje, w końcu stanie się podobny do systemu Windows (mam nadzieję, że się mylę!). Ktoś stworzyłby wtedy nowy system operacyjny oparty na eleganckich zasadach. Coś do przemyślenia. Być może się mylę, nie jestem (oczywiście) zaznajomiony z obecną implementacją. to jest niesamowite, jak przydatne jest rozumienie 30-latka w Linuksie ... przez większość czasu!

Z tego, co zbieram, głównym powodem jest to, że przydatna jest możliwość zmiany nazw katalogów bez bałaganu w uruchomionych programach, które używają swojego katalogu roboczego do odwoływania się do innych plików. Załóżmy, że używasz Wine do uruchamiania ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exei ~/.winezamiast tego chcesz przenieść cały prefiks . Jeśli z jakiegoś dziwnego powodu Firefox uzyskiwał dostęp drive_c/windows, odwołując się do ../../windows, zmiana nazwy ~/.newwineprefixprzerywa implementacje ..tego śledzenia katalogu nadrzędnego jako ciąg tekstowy zamiast i-węzła.

Przechowywanie i-węzła pojedynczego katalogu nadrzędnego musi być prostsze niż próba śledzenia każdej ścieżki zarówno jako ciągu tekstowego, jak i serii i-węzłów.

Innym powodem jest to, że źle działające aplikacje mogą tworzyć pętle. Aplikacje działające powinny mieć możliwość sprawdzenia, czy i-węzeł przenoszonego katalogu jest taki sam, jak i-węzeł dowolnego zagnieżdżonego katalogu, do którego się przenosi, tak jak nie można przenieść katalogu do siebie, ale może to nie być wymuszone na poziomie systemu plików.

Jeszcze innym powodem może być to, że gdybyś mógł hardlinkować katalogi, chciałbyś uniemożliwić hardlinkowanie katalogu, którego nie mógłbyś zmodyfikować. findma względy bezpieczeństwa, ponieważ służy do usuwania plików utworzonych przez innych użytkowników z katalogów tymczasowych, co może powodować problemy, jeśli użytkownik zmieni prawdziwy katalog na dowiązanie symboliczne podczas findwywoływania innego polecenia. Możliwość twardego połączenia ważnych katalogów zmusiłaby administratora do dodania dodatkowych testów, findaby uniknąć ich wpływu. (Ok, już nie możesz 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ą redundancję w przypadku uszkodzenia lub uszkodzenia systemu plików. Jeśli chcesz ..wyświetlić listę wszystkich katalogów nadrzędnych, które prowadzą do tego linku, aby łatwo znaleźć innego, dowolnego rodzica, jeśli bieżący zostanie usunięty, nie tylko naruszasz ideę równości linków twardych, musisz zmienić sposób, w jaki system plików przechowuje i używa i-węzłów. Użycie programów w traktowaniu ścieżek jako serii (unikalnej dla każdego twardego łącza) i-węzłów katalogu uniknęłoby tego, ale nie uzyskałby nadmiarowości w przypadku uszkodzenia systemu plików.