Czy katalog jest usuwany, gdy jego liczba twardych linków osiągnie wartość 0?

Czy katalog jest usuwany, gdy jego liczba twardych linków osiągnie wartość 0?

Katalog zawsze ma co najmniej 2 jako liczbę twardych dowiązań, z powodu .. Czy rm -rw katalogu, czy liczba linków twardych zmniejsza się z 2 do 0 o 2 zamiast 1?

Czy liczba twardych dowiązań katalogu może wynosić 1?

Dzięki.

Po pierwsze, nie wszystkie systemy plików używają .i ..jako twarde linki. jest to udokumentowane w instrukcji wyszukiwania GNU. Zamierzam zignorować te systemy plików do końca mojej odpowiedzi, ponieważ nie zostały zaprojektowane dla Uniksa i tylko komplikują rzeczy bez dodawania przejrzystości. Z tego samego powodu zamierzam również zignorować katalog główny i punkty instalacji.

liczba linków do katalogu nigdy nie jest mniejsza niż dwa z powodu .i ... Liczba podkatalogów jest równa liczbie łączy minus dwa. Z tego powodu nie można połączyć lub rozłączyć katalogu, więc rm -rbędzie statto plik przed usunięciem i używać rmdirzamiast unlinkna katalogach. Dwa wywołania systemowe używają całkowicie różnych ścieżek kodu w jądrze.

Każdy plik w konwencjonalnie zaprojektowanym systemie plików UNIX, którego liczba referencyjna (np. Suma liczby hardlink i liczby otwartych uchwytów plików *) osiąga 0, jest usuwana. Jednak w nowoczesnych systemach UNIX rmdirwywołanie systemowe usuwa pusty katalog w jednej operacji zamiast usuwania .i ..jeden po drugim.

Jednak w historycznych systemach UNIX to wywołanie systemowe nie istniało. Zamiast tego rmdir polecenie było programem setuid ( można tu znaleźć kod źródłowy ), który sprawdził, czy katalog jest pusty (inny niż wpisy specjalne), a następnie usunął ..i ., w tej kolejności, a następnie usunął sam katalog, wszystko za pomocą unlinkwywołanie systemowe, którego tylko root mógł używać w katalogach (dlatego polecenie było setuid). W tych systemach liczba odsyłaczy do katalogu wynosiłaby na chwilę 1 po .usunięciu, ale przed usunięciem katalogu z katalogu nadrzędnego, wynosiłaby 0.

rmPolecenia, nawiasem mówiąc, nawet zapobiec pierwiastek z usuwania katalogów. I rm -rwoła rmdirpolecenie, aby usunąć katalogi po opróżnieniu ich zawartości.

W tych historycznych systemach niewłaściwe użycie unlinkwywołania z programu działającego jako root, uruchomionego do wyścigu z rmdirlub mv, lub utworzenia pliku w procesie, którego bieżący katalog został usunięty (współczesne systemy temu zapobiegają), może spowodować zawieszenie plików lub katalogów które mają twardą liczbę linków powyżej 0, ale nie istnieją w drzewie katalogów. Ten warunek został wykryty przez dchecki nadal jest jednym z testów, fsckponieważ jest fizycznie możliwy w większości systemów plików.

Nawiasem mówiąc, systemy plików nie są wymagane do implementacji katalogów (w tym .i ..) jako normalnych plików, które mają dowiązania twarde. W tych systemach plików liczba dowiązań twardych katalogu zawsze będzie zgłaszana jako 0(ale oczywiście jego istnienie w katalogu nadrzędnym kwalifikuje się do „liczby referencji” równej 1).

Zachowanie usuniętego katalogu (np. Podczas sprawdzania przez proces, który już go otworzył lub ma go jako katalog bieżący) oraz dokładne znaczenie „liczby linków” katalogu są nieokreślone. Na przykład w systemie Mac OS X zgłosi liczbę Hardlink 2 , mimo że nie ma prawdziwych hardlinków. Choć .i ..nie pojawiają się w zestawieniu, katalog może być otwarty i statmoże być wywołana z nazwą .lub ... W systemie Linux, liczba link jest 0, ale .i ..również nadal pracować.

Mac OS X zgłasza również liczbę wszystkich plików w katalogu jako liczbę łączy, a nie tylko liczbę podkatalogów. Ale to nawet wtedy, gdy 2 .i ..zniknęły.

* Obejmuje to normalne otwarte deskryptory, sekcje mapowane w pamięci (w tym np. Wykonywanie plików binarnych i bibliotek współdzielonych) oraz przetwarzanie bieżących katalogów.