Dlaczego jest '.' twardy link w Uniksie?


51

Widziałem wiele wyjaśnień, dlaczego liczba linków do pustego katalogu w systemach operacyjnych opartych na Uniksie wynosi 2 zamiast 1. Wszyscy mówią, że to z powodu „.” katalog, który każdy katalog wskazuje na siebie. Rozumiem, dlaczego mam pojęcie „”. jest przydatny do określania ścieżek względnych, ale co zyskuje się, wdrażając go na poziomie systemu plików? Dlaczego nie tylko powłoki lub wywołania systemowe, które podążają ścieżkami, wiedzą, jak to interpretować?

To, że „..” jest prawdziwym linkiem, ma dla mnie o wiele większy sens - system plików musi przechowywać wskaźnik z powrotem do katalogu nadrzędnego, aby się do niego przejść. Ale nie rozumiem, dlaczego ”. bycie prawdziwym łącznikiem jest konieczne. Wydaje się również, że prowadzi to do brzydkiego specjalnego przypadku w implementacji - można by pomyśleć, że można zwolnić miejsce zajmowane przez i-węzły, które mają liczbę linków mniejszą niż 1, ale jeśli są to katalogi, trzeba sprawdzić link liczy mniej niż 2. Dlaczego niespójność?


1
Gdy masz już ..linki twarde, Twoje oprogramowanie do chodzenia po drzewach musi już mieć wyjątki „nie wykonuj cykli w łączu katalogu nadrzędnego” , więc dodanie złożonego .łącza jest mało skomplikowane .
dmckee,

Odpowiedzi:


37

Rzeczywiście interesujące pytanie. Na pierwszy rzut oka dostrzegam następujące zalety:

Przede wszystkim stwierdzasz, że interpretacja „ .” jako bieżącego katalogu może być wykonana przez Shell lub przez wywołania systemowe. Ale wpisanie kropki w katalogu faktycznie eliminuje tę konieczność i wymusza spójność na jeszcze niższym poziomie.

Ale nie sądzę, że była to podstawowa idea tej decyzji projektowej.

Podczas tworzenia lub usuwania pliku z katalogu należy także zaktualizować znacznik czasu modyfikacji katalogu. Ten znacznik czasu jest przechowywany w jego i-węźle. Numer i-węzła jest przechowywany w odpowiednim wpisie katalogu.

JEŻELI nie będzie tam wpisu kropki, procedury będą musiały wyszukać numer i-węzła przy wpisie dla tego katalogu w katalogu nadrzędnym, co spowodowałoby ponowne wyszukiwanie katalogu.

ALE na szczęście jest kropka w bieżącym katalogu. Procedura, która dodaje lub usuwa plik w bieżącym katalogu, musi po prostu wrócić do pierwszego wpisu (gdzie zwykle znajduje się wpis kropki) i natychmiast znalazła numer i-węzła dla bieżącego katalogu.

Jest jeszcze trzecia fajna rzecz na temat wprowadzania kropek:

Gdy fscksprawdza zgniły system plików i ma do czynienia z niepołączonymi blokami, które również nie znajdują się na liście wolnej, łatwo jest sprawdzić, czy blok danych (interpretowany jako lista katalogów) ma pozycję kropki wskazującą na i-węzeł co z kolei wskazuje na ten blok danych. Jeśli tak, ten blok danych można uznać za utracony katalog, który należy ponownie połączyć.


Bardzo przydatna odpowiedź.
Navaneeth KN

6
Komentarz na temat procedur wyszukujących i-węzeł katalogu jest fałszywy. Procedury jądra nie muszą wyszukiwać .w bieżącym katalogu. Chyba że można znaleźć jądro, w którym tak naprawdę działa (wątpię ...)
Dietrich Epp

1
Zgadzam się z @DietrichEpp; aby system mógł przede wszystkim patrzeć na pozycje katalogu , musi już wiedzieć o i-węzle - ponieważ w ten sposób dociera do bloków danych zawierających pozycje katalogu.
Lqueryvg

10

(Hmm: poniższe jest teraz trochę epickie ...)

Projektowanie katalogu na systemach plików Unix (które mają być pedantyczne, zazwyczaj są, ale niekoniecznie dołączone do systemów operacyjnych UNIX), zapewnia wspaniały wgląd, który faktycznie zmniejsza liczbę wymaganych specjalnych przypadków.

„Katalog” to tak naprawdę tylko plik w systemie plików. Cała rzeczywista zawartość plików w systemie plików jest w i- węzłach (z twojego pytania widzę, że już znasz niektóre z tych rzeczy). I-węzły na dysku nie mają żadnej struktury - to tylko duża liczba ponumerowanych bloków bajtów, rozmieszczonych na dysku jak masło orzechowe. To nie jest użyteczne i rzeczywiście jest odpychające dla każdego, kto ma odrobinę schludności.

Tylko specjalny-węzła jest liczba iwęzeł 2 (nie oznacza 0 lub 1, z uwagi na tradycji); i-węzeł 2 to plik katalogu: katalog główny . Kiedy system montuje system plików, „wie”, że musi przeczytać i-węzeł 2, aby się uruchomić.

Plik katalogu to tylko plik o wewnętrznej strukturze, który jest przeznaczony do odczytu przez opendir (3) i znajomych. Możesz zobaczyć jej wewnętrzną strukturę udokumentowaną w katalogu (5) (w zależności od systemu operacyjnego); jeśli na to spojrzysz, zobaczysz, że pozycja pliku katalogu prawie nie zawiera informacji o pliku - to wszystko w i-węzle pliku. Jedną z niewielu rzeczy, które są szczególne w tym pliku, jest to, że funkcja open (2) wyświetli błąd, jeśli spróbujesz otworzyć plik katalogu w trybie, który pozwala na zapis. Różne inne polecenia (aby wybrać tylko jeden przykład hexdump), odmawiają normalnego działania z plikami katalogów, tylko dlatego, że prawdopodobnie nie tego chcesz (ale to jest ich szczególny przypadek, a nie system plików).

Twrdym jest niczym więcej ani mniej niż wpisu mapie pliku o za. Możesz mieć dwa (lub więcej) wpisy na takiej mapie, które oba mapują na ten sam numer i-węzła: dlatego i-węzeł ma zatem dwa (lub więcej) twarde łącza. To wyjaśnia również, dlaczego każdy plik ma co najmniej jeden „twardy link”. I-węzeł ma liczbę odwołań, która rejestruje, ile razy wspomniany i-węzeł jest wymieniony w pliku katalogu gdzieś w systemie plików (jest to liczba, którą widzisz, gdy to robisz ls -l).

OK: teraz dochodzimy do sedna.

Plik katalogu jest mapą ciągów („nazw plików”) na liczby (liczby i-węzłów). Te liczby i-węzłów są liczbami i-węzłów plików, które znajdują się w tym katalogu. Pliki znajdujące się w tym katalogu mogą zawierać inne pliki katalogu, więc ich numery i-węzłów będą należeć do tych wymienionych w katalogu. Tak więc, jeśli masz plik /tmp/foo/bar, to plik katalogu foozawiera wpis dla bar, odwzorowanie tego ciągu na i-węzeł dla tego pliku. W pliku katalogu znajduje się także wpis dotyczący pliku /tmpkatalogu, fooktóry znajduje się w katalogu /tmp.

Gdy tworzysz katalog za pomocą mkdir (2), ta funkcja

  1. tworzy plik katalogu (z pewnym numerem i-węzła) o właściwej strukturze wewnętrznej,
  2. dodaje pozycję do katalogu nadrzędnego, mapując nazwę nowego katalogu na ten nowy i-węzeł (który odpowiada za jeden z łączy),
  3. dodaje wpis do nowego katalogu, mapując ciąg „.” do tego samego i-węzła (dotyczy to drugiego łącza) i
  4. dodaje kolejny wpis do nowego katalogu, mapując ciąg „..” na i-węzeł pliku katalogu, który zmodyfikował w kroku (2) (odpowiada to większej liczbie twardych łączy widocznych w plikach katalogu zawierających podkatalogi ).

W rezultacie (prawie) jedynymi wyjątkowymi przypadkami są:

  • Funkcja open (2) utrudnia strzelanie sobie w stopę, uniemożliwiając otwieranie plików katalogu do pisania.
  • Funkcja mkdir (2) ułatwia i upraszcza dodawanie kilku nowych wpisów („.” I „..”) do nowego pliku katalogu, aby ułatwić poruszanie się po systemie plików. Podejrzewam, że system plików działałby doskonale bez „.” i „..”, ale korzystanie z niego byłoby uciążliwe.
  • Plik katalogu jest jednym z nielicznych typów plików oznaczonych jako „specjalne” - tak naprawdę nakazuje to, aby open (2) zachowywał się nieco inaczej. Zobacz st_modew stat (2).

(skopiowane z oryginalnego pytania Stackoverflow, 2011-10-20)


1
Mylicie bloki z i-węzłami. W przypadku specjalnym, w przypadku krótkich plików zawartość pliku może znajdować się wewnątrz i-węzła, ale twierdzenie, że i-węzły są nieustrukturyzowane, jest fałszywe. Są bardzo uporządkowane i zawierają prawie wszystkie metadane plików oprócz nazw plików, według których można znaleźć plik. I-węzeł zawiera wskaźniki (bezpośrednie, pośrednie, podwójnie pośrednie itp.) Do bloków na dysku, na których znajduje się zawartość pliku.
Phil P

1
Nie, nie mylę bloków z i-węzłami. I-węzły są abstrakcją siedzącą nad blokami, a celem tego postu było opisanie związku między plikami i katalogami oraz ich zawartością: cała struktura systemu plików pochodzi z plików katalogu. To już wystarczyło, bez utknięcia w implementacjach i-węzłów! (co powiedziawszy, prawdopodobnie mógłbym napisać kilka pierwszych akapitów jaśniej). Ponadto, jak widzicie, wyraźnie stwierdzam, że wszystkie informacje o pliku (oprócz jego nazwy) znajdują się w i-węzle, a nie w pliku katalogu.
Norman Gray,

@NormanGray: Nawet gdy się bronisz, strzelasz sobie w stopę. Powiedziałeś: „Cała zawartość plików w systemie plików jest w i-węzłach…” To źle.  Właściwości / atrybuty pliku (np. Właściciel, uprawnienia, czas modyfikacji itp.) Są przechowywane w i-węźle. Zawartość zwykłego pliku są przechowywane w blokach danych. Jeśli nie chcesz zagłębiać się w implementacje i-węzłów, nie rób tego, ale proszę nie wprowadzaj w błąd nadmiernych uproszczeń.
G-Man mówi „Reinstate Monica”
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.