W jaki sposób katalog jest „specjalnym typem pliku”?

Odpowiedzi:

19

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 .

Złotowłosa
źródło
2
POSIX.1-2008 dodaje kilka wywołań systemowych ( openat, fstatat, itd), które wykorzystują deskryptorów odnoszących się do katalogów.
zwolnij
2
Co ciekawsze, możesz utworzyć 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”.
Kevin
13

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:

  • spinki do mankietów
  • gniazda
  • pomysłowość

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.

hymie
źródło
1
A to znacznie ułatwia życie, ponieważ nie musisz robić nic inaczej, tylko dlatego, że jest to katalog. Dotyczy to pisania programów, a także operacji z wiersza poleceń (lub GUI).
gbarry
1
Katalog zawiera dane: dane opisujące pliki zawarte w katalogu. Zupełnie możliwe jest uzyskanie dostępu do katalogu (choć być może nie ze standardowym otwartym połączeniem) i samodzielne odczytanie tych danych, choć (jak zauważa Bruce Ediger w swojej odpowiedzi) dane te nie są zbyt użyteczne, chyba że znasz format.
jamesqf
11

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.

Bruce Ediger
źródło
1
Nadal możesz dziś otworzyć katalog i odczytać go jako plik w niektórych wariantach Uniksa, na przykład nadal jest to możliwe w FreeBSD 10.1. (Może ≠ powinien)
Gilles 'SO - przestań być zły'
@Gilles Myślę, że byłoby bardzo logiczne, gdyby katalog skopiowany przez dd był w gruncie rzeczy równoważny cp --link dir1/* dir2, chociaż nie jestem pewien jego użyteczności.
Peter mówi, że przywróć Monikę
3

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.

psusi
źródło
Nie jest tak łatwo ze wszystkimi systemami plików - na przykład w Apple HFS + jest tylko jedno duże drzewo B + zawierające wszystkie nazwy ścieżek, jeśli dobrze pamiętam - ale ta obserwacja jest trafna dla systemów plików Unix aż do plików BSD BSD, które prawdopodobnie myśleli o tym autorzy cytowanego samouczka.
zwolnij
2

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.

Henri Kynsilehto
źródło
-3

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

stóg
źródło
2
Nie, tylko 1 i-węzeł może wskazywać na ten sam plik. Chociaż ten sam i-węzeł może istnieć jednocześnie w wielu katalogach (lub pod wieloma nazwami). Łatwa kontrola: 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.
peterh mówi o przywróceniu Moniki
@peterh Deskryptory plików są unikalne tylko dla procesu. możesz wytłumaczyć?
Alamin
1
@ Md.AlaminMahamud Nie jest prawdą, że jeśli proces 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).
Peter mówi, że przywróć Monikę
1
@ Md.AlaminMahamud Cóż, teraz nie jestem bardzo pewny, na przykład, jeśli 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.
Peter mówi, że przywróć Monikę