Czy ktoś może wyjaśnić, dlaczego Linux jest zaprojektowany jako jedno drzewo katalogów?
Podczas gdy w systemie Windows możemy mieć wiele dysków takich jak C:\
i D:\
, w systemie Unix jest jeden katalog główny. Czy jest jakiś konkretny powód?
filesystems
mount
directory-structure
użytkownik2720323
źródło
źródło
C:
aD:
są punkty mocowania w systemie Windows, jak również. Odpowiednikiem systemu Windows/
jest toMy Computer
, że wszystko jest zamontowane pod tym./
w Linuksie jest to samo co C: w MSDOS / Windows, kiedy tak naprawdę nie jest to to samo.C:
,D:
a materiał jest po prostu zgodność z DOS i Win32; Windows NT ma wewnętrznie nieco UNIX-podobnego obiektu hierarchii były litery dysków (i ogólnie rzeczy Win32) to tylko symboliczne linki do „prawdziwych” obiektach (c:\file.txt
w rzeczywistości\??\c:\file.txt
, ze\??\c:
jest dowiązaniem do np\device\harddisk0\partition1
). Patrz np. TutajOdpowiedzi:
Ponieważ system plików Unix wyprzedza Windows o wiele lat, można ponownie sformułować pytanie: „Dlaczego Windows używa osobnego oznaczenia dla każdego urządzenia?”.
Hierarchiczny system plików ma tę zaletę, że każdy plik lub katalog można znaleźć jako element podrzędny katalogu głównego. Jeśli musisz przenieść dane na nowe urządzenie lub urządzenie sieciowe, lokalizacja w systemie plików może pozostać taka sama, a aplikacja nie zobaczy różnicy.
Załóżmy, że masz system, w którym system operacyjny jest statyczny i istnieje aplikacja, która ma wysokie wymagania we / wy. Możesz zamontować / usr tylko do odczytu i umieścić / opt (jeśli aplikacja tam mieszka) na dyskach SSD. Hierarchia systemu plików nie zmienia się. W systemie Windows jest to o wiele trudniejsze, szczególnie w przypadku aplikacji, które domagają się życia pod C: \ Program Files \
źródło
DISK0:
lubSY:
doA:
.Wynika to częściowo z powodów historycznych, a częściowo z tego powodu, że ma to większy sens.
Multics
Multics był pierwszym systemem operacyjnym, który wprowadził hierarchiczny system plików, jaki znamy dzisiaj, z katalogami, które mogą zawierać katalogi. Powołując się na „Ogólny cel systemu plików do dodatkowego przechowywania” RC Daley i PG Neumann:
Podobnie jak w wielu innych aspektach, Multics szukało elastyczności. Użytkownicy mogą pracować w poddrzewie systemu plików i zignorować resztę, nadal korzystając z katalogów, aby uporządkować swoje pliki. Katalogi były również używane do kontroli dostępu - atrybut READ pozwalał użytkownikom na listę plików w katalogu, a atrybut EXECUTE pozwalał użytkownikom na dostęp do plików w tym katalogu (podobnie jak wiele innych funkcji, żył w Uniksie).
Multics przestrzegał także zasady posiadania pojedynczej puli pamięci. Artykuł nie porusza tego aspektu. Pojedyncza pula pamięci pasowała do ówczesnego sprzętu: nie było żadnych wymiennych urządzeń pamięci, a przynajmniej takich, na których użytkownicy by się przejmowali. Multics miał oddzielną pulę pamięci kopii zapasowych, ale była ona przezroczysta dla użytkowników.
Unix
Unix czerpał wiele inspiracji z Multics, ale dążył do uproszczenia, podczas gdy Multics do elastyczności.
Pojedynczy hierarchiczny system plików dobrze pasował do systemu Unix. Podobnie jak w przypadku Multics, pule pamięci zwykle nie były istotne dla użytkowników. Były jednak urządzenia wymienne i Unix udostępnił je użytkownikom za pomocą poleceń
mount
iumount
(zarezerwowanych dla „superużytkownika”, tj. Administratora). W „Systemie podziału czasu UNIX” Dennis Ritchie i Ken Thompson wyjaśniają:Hierarchiczny system plików ma również tę zaletę, że koncentruje złożoność zarządzania wieloma urządzeniami pamięci masowej w jądrze. Oznaczało to, że jądro było bardziej złożone, ale dzięki temu wszystkie aplikacje były prostsze. Ponieważ jądro musi dbać o urządzenia sprzętowe, ale większość aplikacji nie, jest to bardziej naturalny projekt.
Windows
Windows śledzi swoje pochodzenie z powrotem do dwóch linii: VMS , system operacyjny pierwotnie zaprojektowany dla minikomputera VAX oraz CP / M , system operacyjny zaprojektowany dla wczesnych mikrokomputerów Intel.
VMS miał rozproszony hierarchiczny system plików, Files-11 . W Files-11 pełna ścieżka do pliku zawiera nazwę węzła, oznaczenie konta w tym węźle, nazwę urządzenia, ścieżkę do drzewa katalogów, nazwę pliku, typ pliku i numer wersji. VMS miał potężną funkcję logicznej nazwy umożliwiającą definiowanie skrótów do określonych katalogów, więc użytkownicy rzadko musieliby dbać o „rzeczywistą” lokalizację katalogu.
CP / M został zaprojektowany dla komputerów z 64kB pamięci RAM i dyskietką, więc poszedł za prostotę. Nie było katalogów, ale odwołanie do pliku może zawierać wskazanie dysku (
A:
lubB:
).Kiedy MS-DOS 2.0 wprowadził katalogi, zrobił to ze składnią kompatybilną z MS-DOS 1, który sam był zgodny z CP / M. Tak więc ścieżki zostały zrootowane na dysku o nazwie jednoliterowej. (Również znak ukośnika
/
został użyty w VMS i CP / M do uruchomienia opcji wiersza poleceń, więc inny znak musiał zostać użyty jako separator katalogu. Dlatego DOS i później Windows używają ukośnika odwrotnego, chociaż niektóre komponenty wewnętrzne również obsługują ukośnik ).Windows zachował zgodność z DOS i podejściem VMS, więc zachowywał pojęcie liter dysku, nawet gdy stały się mniej istotne. Dzisiaj pod maską Windows używa ścieżek UNC ( pierwotnie opracowanych przez Microsoft i IBM dla OS / 2 , pokrewnych przodków). Chociaż jest to zarezerwowane dla zaawansowanych użytkowników (prawdopodobnie ze względu na wagę historii), system Windows pozwala na montowanie przez punkty ponownej analizy .
źródło
A:
iB:
była przyzwoitą konwencją umożliwiającą rozróżnienie stacji dyskietek, jeśli posiadasz dwie z nich. Gdy dodano obsługę dysków twardych w MS-DOS 2.0,C:
oznaczenie dysku pozwoliło na kompatybilność wsteczną, traktując HD jako jedną DUŻĄ dyskietkę.Nie ma obaw dotyczących bezpieczeństwa związanych z posiadaniem jednego drzewa katalogów.
Faceci, którzy zaprojektowali Unix, mieli spore doświadczenie z systemami operacyjnymi, które wymagały od użytkowników, aby wiedzieć, jakie urządzenie fizyczne zawiera dane zasoby. Ponieważ celem systemu operacyjnego jest stworzenie abstrakcyjnej maszyny na prawdziwym sprzęcie, pomyśleli, że o wiele łatwiej jest zrezygnować z adresowania zasobów według ich fizycznej lokalizacji i postanowili umieścić wszystko w jednym drzewie nazw.
To tylko jedna część geniuszu stojącego za projektem Uniksa .
źródło
Zauważ, że nazwy liter dysków z MS-DOS, które zachowują się we współczesnym systemie Windows, są tutaj czerwonym śledziem. Nazwy liter dysków nie są najlepszą reprezentacją struktury systemu plików, która ma wiele katalogów głównych. Są słomkowym wdrożeniem takiego systemu.
Prawidłowo zaimplementowany system plików, który obsługuje wiele katalogów głównych, umożliwia dowolne nazewnictwo woluminów, takich jak
dvdrom:/path/to/file.avi
. Takie jak system pozbyłby się śmiesznych problemów z interfejsem użytkownika, które nękają system Windows. Na przykład, jeśli podłączysz urządzenie takie jak kamera, interfejs użytkownika Eksploratora Windows sprawi, że uwierzysz, że istnieje urządzenie o nazwie Kamera (lub cokolwiek innego) i że masz ścieżkę podobną do tejComputer\Camera\DCIM\...
. Jeśli jednak wytniesz i wkleisz tekstową wersję tej ścieżki w Eksploratorze, to tak naprawdę nie działa, ponieważ niektóre składniki nazwy ścieżki to fikcja interfejsu użytkownika, nieznana systemowi operacyjnemu. W prawidłowo wdrożonym systemie z wieloma źródłami byłoby dobrze: byłobycamera:\DCIM\...
ścieżka rozpoznawana jednolicie na każdym poziomie w systemie. Co więcej, jeśli przeniesiesz stary dysk twardy ze starego komputera, nie utkniesz z jakąś nazwą litery dyskuF:
, ale raczej będziesz mógł nazwać go tak, jak chceszold-disk:
.Tak więc, jeśli Unix miałby wiele katalogów głównych w strukturze systemu plików, byłoby to robione w taki sposób, a nie w MS-DOS i Windows z jednuliterowymi nazwami dysków. Innymi słowy, porównajmy tylko schemat Unixa z dobrym projektem z wieloma rootami.
Dlaczego więc Unix nie ma rozsądnej implementacji z wieloma rootami, na korzyść rozsądnej implementacji z jednym rootem? To chyba tylko dla uproszczenia. Punkty montowania zapewniają wszystkie funkcje dostępu do woluminów poprzez nazwy. Nie ma potrzeby rozszerzania przestrzeni nazw o dodatkową składnię prefiksu.
Z matematycznego punktu widzenia każdy rozłączny wykres drzewa („las”) może zostać dołączony przez dodanie węzła głównego i uczynienie z niego elementów rozłącznych.
Co więcej, jest bardziej elastyczny, że woluminy nie muszą znajdować się na poziomie głównym. Ponieważ nie ma specjalnej składni oznaczającej głośność (jest to tylko ścieżka), punkty montowania mogą znajdować się w dowolnym miejscu. Jeśli wprowadzą w trzech starych dysków na komputerze, można mieć je jako
/old-disk/one
,/old-disk/two
itd Można organizować dyski jednak chcesz, sposób organizowania plików i katalogów.Można pisać aplikacje, które zależą od ścieżek, a ważność ścieżek można zachować podczas ponownej konfiguracji urządzeń pamięci masowej. Na przykład aplikacje mogą korzystać ze znanych ścieżek, takich jak
/var/log
i/var/lib
. Od Ciebie zależy, czy/var/log
i/var/lib
na tym samym woluminie dyskowym, czy na oddzielnym. Możesz migrować system do nowej topologii pamięci, zachowując ścieżki.Punkty montowania są dobrym pomysłem, dlatego system Windows ma je od około 2000 roku.
źródło
FTP:
wolumin, który umożliwił ci dostęp do plików na dowolnym serwerze FTP ze ścieżką podobną doFTP:hostname/path/to/file
.Zarówno * nix, jak i Windows montują dyski. W systemie Windows są one automatycznie montowane w punktach montowania, które domyślnie mają rosnącą kolejność alfabetyczną. Te wartości domyślne to:
A:
iB:
=> dyskietkiC:
=> pierwsza partycja pierwszego dysku twardegoD:
=> następna partycja lub następny dysk twardy lub napęd CD / DVD, jeśli nie ma innych partycji.Każdy z tych punktów montowania jest katalogiem.
W * nix o punktach montowania decyduje użytkownik. Na przykład mam jedną partycję zamontowaną jako
/
, a drugą jako/home
. Tak,/home
to osobny napęd, byłoby odpowiednikiem powiedzeniaE:
na Windows.W obu przypadkach, Windows i * nix, punkty montowania są osobnymi katalogami. Jedyna różnica polega na tym, że w * nix te osobne katalogi są podkatalogami
/
,C:
podczas gdy w Windows każdy punkt montowania jest montowany bezpośrednio pod/
,My Computer
powiedzmy , pod .Z punktu widzenia użytkownika główną zaletą jest to, że mocowania są całkowicie przezroczyste. Nie muszę wiedzieć, że katalog
/home
znajduje się na osobnej partycji. Mogę po prostu użyć go jako normalnego katalogu. Zamiast tego, w DOS, musiałbym jawnie nazwać to nazwą punktu montowania, powiedzmyE:\home
Napędy zewnętrzne są montowane w prawie taki sam sposób w obu systemach. Powiedz
D:
dla Windows i/mnt/cdrom
Linux. Każdy z nich jest katalogiem, naprawdę nie widzę różnicy. Po włożeniu dysku CD-ROM do napędu w systemie Windows dysk jest montowanyD:
tak jak w systemie Linux.źródło
Zgadzam się z powyższymi odpowiedziami, zwłaszcza odpowiedzią Douga O'Neala, ale myślę, że wszyscy coś pomijają, podobnie jak wyraźne punkty montowania urządzeń, takie jak MS-DOS „C:” lub „A:”.
Rob Pike napisał The Hideous Name o składni nazw, ale Russ Cox sprowadził to :
Jedna przestrzeń nazw, w której urządzenia mogą być dowolnie montowane, pozwala na naprawdę elastyczne operacje. Regularnie używam
/mnt/sdb1
i/mnt/cdrom
tymczasowo umieszczam nieużywany dysk lub dysk CD w całym systemie plików. Często zdarza się, że katalogi domowe znajdują się na serwerze NFS, więc bez względu na to, na jakiej maszynie się logujesz,$HOME
wszędzie to samo .Sprowadza się to do tego: posiadanie specjalnej składni dla specjalnych rzeczy nakłada określone ograniczenia na to, co możesz zrobić. Jeśli możesz zamontować tylko nieużywany dysk, dysk CD lub DVD lub sieciowy system plików / „share” na „E:” lub „W:” lub czymkolwiek, masz znacznie mniejszą elastyczność.
źródło
proto://specifichost.domain.tld/topleveldir/middle/specificdoc.html
.proto://
biznes jest pragmatyczną koniecznością. Nie można oczekiwać, że każde oprogramowanie będzie wiedzieć o wszystkich dostępnych schematach URI. Dlatego pomocne może być określenie, kiedy kończy się identyfikator schematu, a reszta identyfikatora URI zaczyna się.To niemądre. System Windows ma również jeden punkt hierarchii. Ale jest ukryty i niestandardowy. Jak większość rzeczy Windows.
W tym przypadku jest to koncepcja „Mój komputer”. Jest to odpowiednik root (/) w Uniksie. Pamiętaj, że root to koncepcja, która istnieje w jądrze. lubisz to czy nie. Podobnie jak Windows traktuje „Mój komputer”. oczywiście możesz zamontować partycję na rootie w Uniksie i tak właśnie robi większość ludzi. I wiele rzeczy będzie patrzeć na określoną ścieżkę dla rzeczy (np. / Etc /), ale nie jesteś przez to ograniczony. Jak najbardziej, zamontuj dyski w / C: /. nie jest to zabronione w Unixie.
C: \ nie jest katalogiem głównym w systemie Windows, jest punktem podłączenia jednej partycji. Które MUSZĄ znajdować się na najwyższym poziomie „Mój komputer”. Będąc w Uniksie, możesz zamontować partycję pod dowolnym innym drzewem. Tak więc linux może mieć C: zamontowany,
/
podczas gdy D: zamontowany/mnt/d/
... lub nawet zainstalowany,/
ale jest to trudne i zależy od tego, jak zachowują się dwa systemy plików podczas montowania na już zamontowanej ścieżce.Możesz uzyskać dokładnie to samo, co masz w przypadku systemu Windows, „zmuszając” się do przestrzegania tych samych ograniczeń, które narzucają ci okna.
Następnie musisz przekazać opcje montowania w opcjach rozruchu. ponieważ nie będziesz mieć / etc / ... ale to także symuluje ograniczenia, jakie narzuca Windows, ponieważ to robi.
źródło
My Computer
.My Computer
jest węzłem głównym hierarchii powłoki. zawiera dyski, jeśli mają literę dysku , ale także panel sterowania i dowolny podłączony system Windows Phone. Hierarchia powłoki używa ścieżek PIDL zamiast ścieżek.CreateFile
przekazywania „Mój komputer” lub innych folderów powłoki; jest to abstrakcja rozumiana tylko przez kod związany z powłoką, wszystkie wywołania jądra (a zatem 90% aplikacji, ponieważ zarządzanie plikami w większości języków jest realizowane za pomocą interfejsów API plików jądra) nic o tym nie wiedzą. Foldery powłoki są użyteczne tylko wtedy, gdy programy używają „standardowych okien dialogowych” (które nie rozumieją przestrzeni nazw powłoki) i tylko wtedy, gdy wybrane pliki są bezpośrednio mapowane na „prawdziwą” (= zrozumiałą dla jądra) ścieżkę.Powód, dla którego Windows ma litery dysku, prawdopodobnie sięga jeszcze dalej niż Microsoft i DOS. Przypisywanie liter do dysków wymiennych było powszechne w systemach IBM, więc Microsoft mógł po prostu działać zgodnie z instrukcjami IBM, kopiując CP / M. I początkowo DOS i tak nie miał katalogów.
Gdy MS-DOS działał na komputerach z jednym lub dwoma dyskami wymiennymi i bez stałych nośników, tak naprawdę nie potrzebowałeś systemu plików z katalogami. Na jednym, a może na dwóch 180-kilobajtowych dyskach nigdy nie było wystarczająco dużo plików, aby mieć problemy z ich organizacją.
https://en.wikipedia.org/wiki/Drive_letter_assignment
źródło
W rzeczywistości Linux oparty jest na Uniksie (lub jest Uniksem, patrz dyskusja ), a Unix pochodzi ze środowiska mainframe, gdzie używanie wielu urządzeń było dość oczywiste. Montowanie urządzeń w obrębie jednego drzewa katalogów zapewnia maksymalną elastyczność i nie ogranicza liczby urządzeń, do których system operacyjny może uzyskać dostęp.
Z drugiej strony litery DOS dla napędów to dobry projekt na komputer z 1 lub 2 stacjami dyskietek i pojedynczym dyskiem. Duża dyskietka 5,25 'to zawsze A :, mała 3,5' to zawsze B :, a napęd dyskowy to zawsze C :. Zawsze wiesz, czy skopiujesz plik na dyskietkę lub gdzieś na dysk. Nie potrzebujesz żadnej elastyczności, jeśli nie możesz fizycznie podłączyć więcej niż 2 stacji dyskietek i 2 (lub 4) dysków twardych.
Projekt DOS był bardziej przyjazny dla użytkownika końcowego, podczas gdy projekt Uniksa jest przyjazny dla administratora. Teraz litery dysków są obciążeniem dla systemu Windows, użytkownicy bardziej polegają na automatycznym otwieraniu okna eksploratora z wymienną zawartością dysku niż znajomością jego litery ... Ubuntu robi to samo.
źródło
Właściwie to nie prawda. Windows używa innego schematu ścieżek (cóż, nie tego samego)
„Litery jednostek” to tylko coś, co łatwo zapamiętać, ścieżki, dyski i partycje.
Ścieżki ARC definiują ścieżkę do pliku w systemie Windows (ale są widoczne dla użytkownika tylko podczas rozruchu):
http://support.microsoft.com/kb/102873
https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows
W systemie Windows NT nie ma związku między dyskami, partycjami i literami jednostek: Możesz „umieścić” cały wolumin w folderze (np .: c: \ myseconddisk może być całym dyskiem fizycznym!)
źródło
Dwie rzeczy, na które chciałbym zwrócić uwagę -
źródło
Jeśli spojrzysz w przeszłość, zobaczysz również, że Unix zaczął się w czasie 8 ścieżkowych systemów taśm dla audio i 9 ścieżkowych systemów danych IBM (8 ścieżek / 8 bitów dla danych, jeden dla parzystości). Technicznie bardzo podobnie.
W tym czasie informacje o lokalizacji plików były przechowywane w częściach informacji na taśmie oraz w przód i wstecz zdefiniowane podczas odczytywania danych z taśmy (jak plik, z pozycją początkową i sygnaturą końcową); wyjaśnia również, dlaczego nie miałeś tylko jednego FAT na początku dysku - miałeś wiele, aby przyspieszyć wyszukiwanie. A jeśli miałeś wiele napędów, były one połączone w / dev i poprzez adres pliku przeniesionego między urządzeniami.
Wierzę, że możesz mieć pogląd, że zaczął się po prostu wcześniej i że decyzja za obszarem MS Dos (CP / M) i późniejszym Windows NT jest po prostu związana z literami dysków mainframe VM zamiast z pojedynczym punktem wejścia, ponieważ w tym czasie wyglądała bardziej współczesne, dzisiejsze ilości danych nie istniały i nie sądzili, że ostatecznie nie będziesz mieć wystarczającej liczby liter dysku lub że będzie zbyt zagracony.
Przyporządkowanie napędu 9-ścieżkowego i litery napędu
źródło