Po co przechowywać linki własne i nadrzędne (. I ..) w pozycji katalogu?

11

Rozważ system plików ukierunkowany na niektóre urządzenia osadzone, który robi niewiele więcej niż przechowywanie plików w hierarchicznej strukturze katalogów. W tym systemie plików brakuje wielu operacji, do których możesz być przyzwyczajony w systemach takich jak Unix i Windows (na przykład jego uprawnienia dostępu są zupełnie inne i nie są powiązane z metadanymi przechowywanymi w katalogach). Ten system plików nie dopuszcza żadnego rodzaju twardego lub miękkiego łącza, więc każdy plik ma unikalną nazwę w ścisłej strukturze drzewa.

Czy jest jakaś korzyść z przechowywania łącza do samego katalogu i jego elementu nadrzędnego w strukturze danych na dysku, która reprezentuje katalog?

Większość systemów plików UNIX .i ..wpisy na dysku. Zastanawiam się, dlaczego nie obsługują ich w warstwie VFS (sterownik ogólnego systemu plików). Czy to artefakt historyczny? Czy istnieje dobry powód, a jeśli tak, to który dokładnie, aby ustalić, czy jest on odpowiedni dla mojego systemu wbudowanego?

operating-systems filesystems Gilles „SO- przestań być zły”
źródło
Zawsze myślałem, że są tam tylko wirtualnie, więc programy mogą łatwo uzyskać dostęp do katalogu bieżącego i nadrzędnego. Ciekawe pytanie, ale czy tu należy?
Raphael
@Raphael Zrozumiałbym, gdybyście uważali moje pytanie za zbyt ogólne (→ „pytanie nie jest prawdziwe”), a może „niekonstruktywne”, ponieważ jest ono dość otwarte. Ale nie zgadzam się, że to nie na temat: chodzi o projektowanie systemu plików, jak to się nie dzieje z informatyką? Jeśli uważasz, że to nie na temat, wyjaśnij swoje uzasadnienie dotyczące meta.
Gilles 'SO - przestań być zły'
@Raphael Zredagowałem swoje pytanie, mam nadzieję, że powinno być jasne, że moim punktem widzenia jest projektant systemów operacyjnych osadzonych. Dziękuję za komentarze.
Gilles „SO- przestań być zły”

Odpowiedzi:

2

Posiadanie linków do katalogu nadrzędnego ma dla mnie sens. Gdybyś ich nie miał, zawsze musiałbyś pracować z całą listą katalogów. Na przykład /home/svick/Documents/należałoby przedstawić jako { /, /home/, /home/svick/, /home/svick/Documents }. Jeśli tego nie zrobisz, nie będziesz w stanie znaleźć katalogu nadrzędnego (lub byłoby to bardzo drogie). Jest to nie tylko nieefektywne, ale także niebezpieczne. Jeśli masz dwie takie listy, które się nakładają, mogą one łatwo zsynchronizować się, jeśli przeniesiesz jakiś katalog.

Z drugiej strony, jeśli masz odniesienie do katalogu nadrzędnego, jest to bardziej wydajne i bezpieczniejsze.

Nie widzę żadnego powodu, aby mieć link do bieżącego katalogu. Jeśli masz strukturę reprezentującą jakiś katalog i chcesz uzyskać do niego dostęp, korzystanie z niego .jest zawsze całkowicie niepotrzebne. Z tego powodu oczekiwałbym, że .łącze tak naprawdę nie istnieje w strukturze systemu plików i jest tylko wirtualne.

svick
źródło
2
Ta sama uwaga: dlaczego robi to w każdym systemie plików, a nie w warstwie VFS? Większość systemów plików Linux ma .i ..wpisy.
Gilles 'SO - przestań być zły'
Tak jak powiedziałem, myślę, że jest bardziej wydajny. Możesz pracować tylko z bieżącym katalogiem i uzyskiwać dostęp do jego rodziców tylko wtedy, gdy potrzebujesz. Jeśli nie masz linków nadrzędnych, zawsze musisz zachować wszystkie katalogi na całej ścieżce od katalogu głównego w pamięci. I potrzebujesz tego dla każdego wpisu, którego używasz.
sick
1
@svick: Gilles nie porównuje posiadania linków nadrzędnych z brakiem linków nadrzędnych. Porównuje posiadanie ich w rzeczywistym systemie plików z symulowaniem ich przez pośrednią warstwę kodu (vfs) między rzeczywistym systemem plików a przestrzenią użytkownika.
rgrig
2

Dostajesz mniej specjalnych przypadków. W wielu sytuacjach VFS może obsługiwać „..”, ponieważ obsługuje każdą inną nazwę katalogu.

rgrig
źródło
3
Jeśli katalogi są wirtualne, program (zakładam, że tryb użytkownika) może nadal obsługiwać go jak każdy inny katalog. Naprawdę nie potrzebujesz linków do prezentacji na poziomie magazynu.
Aryabhata
1
Tak, ale dlaczego nie poradzić sobie z tym na warstwie VFS? Dlaczego miałoby istnieć jakieś powiązane miejsce do przechowywania?
Gilles „SO- przestań być zły”
Dlaczego ludzie implementują połączone listy za pomocą wartownika zamiast zajmować się pustą wielkością listy w funkcjach dodawania / usuwania?
rgrig
@rgrig: Dzieje się tak tylko wtedy, gdy interfejs do rozważanej implementacji listy połączonej jest napisany w języku wyjątkowo źle radzącym sobie z indukcyjnymi strukturami danych (C, Java itp.). W tym przypadku problem nie jest istotny, ponieważ warstwa VFS nie jest bezpośrednio dostępna z punktu widzenia użytkownika.
Stéphane Gimenez
@ StéphaneGimenez: Ten problem jest istotny, ponieważ VFS jest napisany w C.
rgrig
2

Jedynym powodem, który mogę sobie wyobrazić, jest następujący scenariusz:

  1. Oryginalna implementacja systemu plików istniała w tym samym formacie katalogów, ale pojęcia ścieżek i podkatalogów nie były wówczas brane pod uwagę (patrz System plików Unix PDP-7 ).

  2. Wtedy ludzie myśleli, że rozdzielczość ścieżki i podkatalogi będą przydatne!

  3. Aby zachować pewną zgodność wsteczną ze starszymi implementacjami, zdecydowano, że .i ..będą przechowywane na dysku, tak jak każdy inny katalog.

Więc może pozostały nam te bezużyteczne artefakty, tylko ze względu na kompatybilność wsteczną z 40-letnim oprogramowaniem? Wiarygodny scenariusz?

Uwaga: Dodanie tych wpisów do listy katalogów również nie było głupie, ponieważ i tak trzeba gdzieś przechowywać numer i-węzła prawdziwego katalogu nadrzędnego (pamiętaj, że w tym czasie dozwolone były twarde linki do katalogów) oraz odniesienie do twojego własny numer i-węzła może być dobrym sprawdzeniem rozsądku.

Stéphane Gimenez
źródło
1

Nie widzę powodu do wdrożenia .ani ..na żadnym z tych poziomów. Jednak jeśli celujesz w systemy osadzone, każdą warstwę, którą możesz zaoszczędzić, może być zarobek w dolarach, więc warto wdrożyć wszystko tak nisko, jak to możliwe.

Jeśli chodzi o ogólną potrzebę .i .., jak wyraziłbyś ścieżki względne bez nich? Przynajmniej ..jest niezbędny dla ścieżek, które opuszczają bieżące poddrzewo. Jeśli nie potrzebujesz takich ścieżek (może drzewo jest prymitywnym sposobem kodowania uprawnień dostępu?), Nie potrzebujesz ...

Raphael
źródło