Czytam ten samouczek Uniksa i natknąłem się na ten cytat ...
Należy tutaj zauważyć, że katalog jest jedynie specjalnym typem pliku.
... ale nie podano żadnych wyjaśnień ani szczegółów. W jaki sposób katalog jest po prostu plikiem?
Odpowiedzi:
Wiele encji w stylu * nix (i innych) systemach operacyjnych jest uważanych za pliki lub ma definiujący aspekt podobny do pliku, nawet jeśli niekoniecznie jest to ciąg bajtów przechowywanych w systemie plików. Dokładnie sposób implementacji katalogów zależy od rodzaju systemu plików, ale ogólnie to, co zawierają, traktowane jako lista, jest sekwencją przechowywanych bajtów, więc w tym sensie nie są one tak wyjątkowe.
Jednym ze sposobów zdefiniowania, czym jest „plik” w kontekście * nix, jest to, że jest on powiązany z deskryptorem pliku . Zgodnie z artykułem wikipedia deskryptor pliku
to abstrakcyjny wskaźnik używany do uzyskiwania dostępu do pliku lub innego zasobu wejścia / wyjścia , takiego jak połączenie rurowe lub sieciowe ...
Innymi słowy, odnoszą się one do różnego rodzaju zasobów, z których / do których można odczytać / zapisać sekwencję bajtów, chociaż źródło / miejsce docelowe tej sekwencji nie jest określone. Innymi słowy, „gdzie” zasobu może być cokolwiek. Definiuje to, że jest to kanał informacyjny. Jest to część tego, dlaczego czasami mówi się, że w unixie „wszystko jest plikiem”. Nie powinieneś brać tego całkowicie dosłownie, ale warto poważnie rozważyć. W przypadku katalogu informacje te dotyczą tego, co znajduje się w katalogu, a na niższym poziomie implementacji, jak je znaleźć w systemie plików.
Katalogi są w tym sensie wyjątkowe, ponieważ w natywnym kodzie C nie są pozornie powiązane z deskryptorem pliku; POSIX API wykorzystuje specjalny rodzaj uchwytu strumień, DIR*. Jednak w rzeczywistości ten typ ma podstawowy deskryptor, który można odzyskać . Deskryptory są zarządzane przez jądro i dostęp do nich zawsze obejmuje wywołania systemowe, dlatego innym aspektem tego, czym jest deskryptor, jest to, że jest to przewód kontrolowany przez jądro systemu operacyjnego. Mają unikalne (na proces) liczby zaczynające się od 0, co zwykle jest deskryptorem standardowego strumienia wejściowego .
openat, fstatat, itd), które wykorzystują deskryptorów odnoszących się do katalogów.
fsync()katalog tylko do odczytu (!) Fd, i ma on dobrze zdefiniowany efekt (w szczególności synchronizuje tworzenie / zmianę nazwy / usuwanie pliku w danym katalogu na dysk, teoretycznie niezbędny krok w „zapisie” do pliku tymczasowego i zmień jego nazwę na oryginalny „idiom”.
W Uniksowym sposobie robienia rzeczy: wszystko jest plikiem.
Katalog to jeden (z wielu) typów plików specjalnych. Nie zawiera danych. Zamiast tego zawiera wskaźniki do wszystkich plików zawartych w katalogu.
Inne typy plików specjalnych:
Ale ponieważ są one uważane za „pliki”, możesz lsje zmieniać, zmieniać ich nazwy i przenosić je oraz, w zależności od rodzaju pliku specjalnego, wysyłać dane do / z nich.
Moja odpowiedź jest zwykłym wspomnieniem, ale w 199x starych uniksach, których było wiele, katalogi były plikami, właśnie oznaczonymi „katalogiem” gdzieś w i-węzle na dysku.
Możesz otworzyć katalog z czymś podobnym open(".", O_RDONLY)i odzyskać użyteczny deskryptor pliku. Możesz przeanalizować zawartość, jeśli przejrzysz /usr/includei znajdziesz poprawną definicję struktury C. Wiem, że zrobiłem to dla systemów SunOS 4.1.x, systemu plików SGS SGI i wszystkich stacji roboczych DEC Mips-CPU dla systemu plików, prawdopodobnie FFS BSD4.2.
To było złe doświadczenie. Standaryzacja na warstwie wirtualnego systemu plików jest dobra dla przenośności, nawet jeśli katalogi nie są już ścisłymi plikami. Warstwy VFS pozwalają nam eksperymentować z systemami plików, w których katalogi nie są plikami, takimi jak ReiserFS lub NFS.
cp --link dir1/* dir2, chociaż nie jestem pewien jego użyteczności.
Katalog wyróżnia się tym, że ma w swoim trybie „d”, mówiąc systemowi plików, że powinien interpretować jego zawartość jako listę innych plików zawartych w katalogu, a nie zwykły plik będący tylko sekwencją bajtów czytane przez aplikację. To wszystko.
Katalogi są plikami, ponieważ systemy Linux używają uniwersalnego modelu we / wy . W modelu wszystko w systemie jest plikiem i można do niego uzyskać dostęp za pomocą tych samych wywołań systemowych i różnych poleceń.
Są specjalnego typu, ponieważ ich i-węzły mają oznaczenie typu pliku i mają specjalną strukturę, która jest tabelą nazw plików i linkami do innych i-węzłów. Te pary plików-linków, zwane również „twardymi linkami”, w i-węźle katalogu wyliczają pliki „wewnątrz” katalogu.
Katalogi służą tylko do porządkowania plików. Gdy plik jest „przenoszony” z katalogu do innego, sam plik nie przenosi się na dysk. Po prostu wpis w jednym i-węźle katalogu jest usuwany i zapisywany w innym i-węźle katalogu.
Przyjęta odpowiedź nie jest całkowicie poprawna. w systemach POSIX „i-węzły” wskazują pliki i katalogi. Deskryptory plików są unikalne tylko dla procesu, a nie w całym systemie. Jednak i-węzły są unikalne, chociaż więcej niż jeden i-węzeł może wskazywać na pojedynczy plik. Skomentowałby zaakceptowaną odpowiedź, ale nie mógł z powodu ograniczeń powtórzeń.
ls -l >test.txt;ln -vf test.txt test2.txt;ls -li test.txt test2.txt. Zobaczysz, że twarde linki mają ten sam numer i-węzła.
fork()s, jego proces potomny będzie miał (poza pewnymi szczególnymi okolicznościami, mianowicie O_CLOEXECflagą) dokładnie takie same jednostki deskryptora plików, jak proces pierwotny. Kolejny przykład: procesy potomne apache są przetwarzane listen()na tym samym deskryptorze pliku gniazda. Ale ta odpowiedź nie dotyczy deskryptorów plików, które są wewnętrzną strukturą danych jądra i istnieją tylko w pamięci jądra. Ta ( fałszywa ) odpowiedź dotyczy pozycji katalogu i i-węzłów, są to byty na dysku (tj. Są to bajty fizyczne na dysku twardym).
fork()zdarzy, a następnie proces potomny seek()s lub close()s, to nie będzie miało wpływu na deskryptor rodzica. Myślę teraz, że deskryptory plików są tylko częściowo strukturami prywatnymi dla procesów. Ale to pytanie nie dotyczy ich, to pytanie dotyczy kierunków / i-węzłów i komentuję całkowicie fałszywą odpowiedź na to pytanie.