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 .
..wskazywać? Zwłaszcza po usunięciu twardego łącza do tego katalogu w katalogu wskazanym przez..? Musi gdzieś wskazać.