Wiem, że „Wszystko jest plikiem” oznacza, że nawet urządzenia mają swoją nazwę pliku i ścieżkę w systemach Unix i podobnych do Unixa, i że pozwala to na używanie wspólnych narzędzi do różnych zasobów, niezależnie od ich charakteru. Nie mogę jednak odróżnić tego od Windows, jedynego innego systemu operacyjnego, z którym pracowałem. Przeczytałem kilka artykułów na temat tej koncepcji, ale myślę, że są one nieco trudne do zrozumienia dla nie-programistów. Wyjaśnienie laika jest tym, czego ludzie potrzebują!
Na przykład, gdy chcę skopiować plik na kartę CF podłączoną do czytnika kart, użyję czegoś takiego
zcat name_of_file > /dev/sdb
Myślę, że w systemie Windows czytnik kart pojawi się jako sterownik, a my zrobimy coś podobnego. Jak więc zmienia się tutaj filozofia „Wszystko jest plikiem”?
źródło
name_of_file
zdarzy się, aby był to właściwy obraz systemu plików, po prostu zniszczyłeś tę kartę CF ...Odpowiedzi:
„Wszystko jest plikiem” to trochę glib. „Wszystko pojawia się gdzieś w systemie plików ” jest bliżej znaku, a nawet wtedy jest bardziej ideałem niż prawem projektowania systemu.
Na przykład gniazda domeny systemu Unix nie są plikami, ale pojawiają się w systemie plików. Możesz użyć
ls -l
gniazda domeny, aby wyświetlać jego atrybuty,cat
dane do / z jednego, modyfikować kontrolę dostępu za pośrednictwemchmod
itp.Ale mimo że zwykłe gniazda sieciowe TCP / IP są tworzone i manipulowane przy użyciu tych samych wywołań systemowych gniazd BSD , co gniazda domenowe w systemie Unix, gniazda TCP / IP nie pojawiają się w systemie plików, ¹ nawet jeśli nie ma szczególnie dobrego powodu, aby Mów prawdę.
Innym przykładem obiektów niebędących plikami pojawiających się w systemie plików jest Linuksa
/proc
plików . Ta funkcja ujawnia dużą ilość szczegółów dotyczących działania jądra w przestrzeni użytkownika , głównie jako wirtualne pliki tekstowe. Wiele/proc
wpisów jest tylko do odczytu, ale wiele z nich/proc
jest również zapisywalnych, więc możesz zmienić sposób działania systemu za pomocą dowolnego programu, który może modyfikować plik. Niestety, tutaj znowu mamy nonideality: Unixy typu BSD generalnie działają bez/proc
, a Unixy System V ujawniają o wiele mniej za pośrednictwem/proc
Linuksa.Po pierwsze, wiele sentymentów, które można znaleźć w Internecie, a także w książkach o uniksowym podejściu do operacji we / wy plików i „pękaniu” systemu Windows pod tym względem, jest przestarzałe. Windows NT naprawił wiele z tego.
Nowoczesne wersje systemu Windows mają zunifikowany system we / wy, podobnie jak Unix, więc możesz czytać dane sieciowe z gniazda TCP / IP za pośrednictwem
ReadFile()
interfejsu API specyficznego dla Windows SocketsWSARecv()
, jeśli chcesz. Dokładnie przypomina to Uniksowy Sposób , w którym można czytać z gniazda sieciowego za pomocą ogólnegoread(2)
wywołania systemowego Unix lub wywołania specyficznego dla gniazdrecv(2)
.²Niemniej jednak system Windows nadal nie przenosi tej koncepcji na ten sam poziom co Unix, nawet tutaj w 2018 roku. Istnieje wiele obszarów architektury Windows, do których nie można uzyskać dostępu za pośrednictwem systemu plików lub których nie można traktować jako plików. Kilka przykładów:
Kierowcy
Podsystem sterowników Windows jest tak bogaty i potężny jak Unix, ale aby pisać programy do manipulowania sterownikami, zazwyczaj musisz używać zestawu sterowników Windows , co oznacza pisanie kodu C lub .NET.
W systemach operacyjnych typu Unix można wiele zrobić ze sterownikami z wiersza poleceń. Prawie na pewno już to zrobiłeś, choćby przekierowując niechciane wyjście do
/dev/null
.³Komunikacja między programami.
Programy Windows nie komunikują się ze sobą łatwo.
Programy wiersza poleceń systemu Unix komunikują się łatwo za pośrednictwem strumieni tekstowych i potoków. Programy GUI są często budowane na programach wiersza poleceń lub eksportują interfejs poleceń tekstowych, dzięki czemu te same proste mechanizmy komunikacji tekstowej działają również z programami GUI.
Rejestr
Unix nie ma bezpośredniego odpowiednika rejestru Windows. Te same informacje są rozproszone w systemie plików, większość w
/etc
,/proc
i/sys
.Jeśli nie widzisz, że sterowniki, potoki i odpowiedź Unixa na rejestr systemu Windows mają coś wspólnego z „wszystko jest plikiem”, czytaj dalej.
Wyjaśnię to szczegółowo, omawiając moje trzy punkty powyżej.
Długa odpowiedź, część 1: Napędy a pliki urządzeń
Załóżmy, że Twój czytnik kart CF jest wyświetlany
E:
w systemie Windows i/dev/sdc
Linux. Co to za praktyczna różnica?Nie jest to tylko niewielka różnica w składni.
W systemie Linux mogę powiedzieć,
dd if=/dev/zero of=/dev/sdc
aby zastąpić zawartość/dev/sdc
zerami.Zastanów się, co to znaczy przez chwilę. Tutaj mam normalny program w przestrzeni użytkownika (
dd(1)
), do którego prosiłem o odczyt danych z urządzenia wirtualnego (/dev/zero
) i zapisanie tego, co odczytano na prawdziwym urządzeniu fizycznym (/dev/sdc
) poprzez zunifikowany system plików Unix.dd
nie wie, że czyta i pisze na specjalnych urządzeniach. Działa równie dobrze na zwykłych plikach lub na mieszance urządzeń i plików, jak zobaczymy poniżej.Nie ma łatwego sposobu na wyzerowanie
E:
dysku w systemie Windows, ponieważ system Windows rozróżnia pliki i dyski, więc nie można używać tych samych poleceń do manipulowania nimi. Najbliżej można zrobić format dysku bez opcji Szybkie formatowanie, która zeruje większość zawartości dysku, ale następnie zapisuje na nim nowy system plików. Co jeśli nie chcę nowego systemu plików? Co jeśli naprawdę chcę, aby dysk był zapełniony tylko zerami?Bądźmy szczodrzy i powiedzmy, że naprawdę chcemy nowego systemu plików
E:
. Aby to zrobić w programie w systemie Windows, muszę wywołać specjalny interfejs API formatowania. ⁴ W systemie Linux nie trzeba pisać programu, aby uzyskać dostęp do funkcji „formatowania dysku” systemu operacyjnego. Wystarczy uruchomić odpowiedni program przestrzeni użytkownika dla danego typu systemu plików, który chcesz utworzyć:mkfs.ext4
,mkfs.xfs
lub co ty. Programy te zapisują system plików na dowolnym/dev
przekazywanym pliku lub węźle.Ponieważ
mkfs
programy typu w systemach Unixy działają na plikach bez sztucznego rozróżniania urządzeń i normalnych plików, oznacza to, że mogę utworzyć system plików ext4 w normalnym pliku na moim Linux-ie:To dosłownie tworzy obraz dysku 1 MiB w bieżącym katalogu o nazwie
myfs
. Następnie mogę zamontować go tak, jak gdyby był to inny zewnętrzny system plików:Teraz mam obraz dysku ext4 z wywołanym plikiem
my-passwd-entry
, który zawiera wpis mojego użytkownika/etc/passwd
.Jeśli chcę, mogę wysadzić ten obraz na mojej karcie CF:
Lub mogę spakować ten obraz dysku, wysłać go pocztą i pozwolić Ci napisać go na wybranym przez Ciebie nośniku , takim jak pamięć USB:
Wszystko to jest możliwe w Linuksie, ponieważ nie ma sztucznego rozróżnienia między plikami, systemami plików i urządzeniami. Wiele rzeczy w systemach Unix albo są pliki, lub są dostępne za pośrednictwem systemu plików tak, że wyglądają jak pliki, lub w jakiś inny sposób spojrzenia na tyle plikopodobnym że mogą one być traktowane jako takie.
Koncepcja systemu plików dla systemu Windows to wielka zaleta; rozróżnia katalogi, dyski i zasoby sieciowe. Istnieją trzy różne składnie, wszystkie połączone w systemie Windows: uniksopodobny
..\FOO\BAR
system ścieżek, litery dysków podobneC:
i ścieżki UNC jak\\SERVER\PATH\FILE.TXT
. Jest tak, ponieważ jest to przyrost pomysłów z Uniksa, CP / M , MS-DOS i LAN Managera , a nie z jednego spójnego projektu. Dlatego w nazwach plików Windows jest tak wiele niedozwolonych znaków .Unix ma zunifikowany system plików, do którego dostęp można uzyskać za pomocą jednego wspólnego schematu. Aby program uruchomiony na Linuksie, nie ma różnicy między funkcjonalne
/etc/passwd
,/media/CF_CARD/etc/passwd
i/mnt/server/etc/passwd
. Pliki lokalne, media zewnętrzne i udziały sieciowe są traktowane w ten sam sposóbWindows może osiągnąć podobne cele jak mój przykład obrazu dysku powyżej, ale musisz użyć specjalnych programów napisanych przez niezwykle utalentowanych programistów. Dlatego w systemie Windows jest tak wiele programów typu „wirtualny dysk DVD” . Brak podstawowej funkcji systemu operacyjnego stworzył sztuczny rynek dla programów, aby wypełnić lukę, co oznacza, że masz grupę ludzi konkurujących o stworzenie najlepszego programu typu wirtualnego DVD. Nie potrzebujemy takich programów w systemach * ix, ponieważ możemy po prostu zamontować obraz dysku ISO za pomocą urządzenia pętlowego .
To samo dotyczy innych narzędzi, takich jak programy do czyszczenia dysków , których nie potrzebujemy również w systemach Unix. Chcesz, aby zawartość Twojej karty CF była nieodwracalnie mieszana, a nie zerowana? Okej, użyj
/dev/random
jako źródła danych zamiast/dev/zero
:W Linuksie nie wymyślamy na nowo takich kół, ponieważ podstawowe funkcje systemu operacyjnego działają nie tylko wystarczająco dobrze, ale działają tak dobrze, że są powszechnie stosowane. Typowy schemat uruchamiania systemu Linux obejmuje obraz dysku wirtualnego, na przykład, utworzony przy użyciu technik takich jak pokazałem powyżej.
Wydaje mi się słuszne, aby wskazać, że gdyby Unix zintegrował we / wy TCP / IP z systemem plików od samego początku, nie mielibyśmy bałaganu
netcat
vssocat
vsNcat
vs , którego przyczyną była ta sama słabość projektowa proliferacja narzędzi do obrazowania i czyszczenia dysków w systemie Windows: brak akceptowalnej funkcji systemu operacyjnego.nc
Długa odpowiedź, część 2: Rury jako pliki wirtualne
Pomimo swoich korzeni w DOS, Windows nigdy nie miał bogatej tradycji wiersza poleceń.
Nie oznacza to, że system Windows nie ma wiersza polecenia lub brakuje wielu programów wiersza polecenia. Windows ma nawet bardzo potężną powłokę poleceń, odpowiednio zwaną PowerShell .
Istnieją jednak domniemane skutki tego braku tradycji wiersza poleceń. Dostajesz narzędzia,
DISKPART
które są prawie nieznane w świecie Windows, ponieważ większość ludzi wykonuje partycjonowanie dysku i takie za pomocą przystawki programu Computer Management MMC. Następnie, kiedy trzeba wykonać skrypt tworzenia partycji, okazuje się, żeDISKPART
nie był tak naprawdę stworzony do obsługi innego programu. Tak, możesz napisać serię poleceń do pliku skryptu i uruchomić goDISKPART /S scriptfile
, ale to wszystko albo nic. Czego naprawdę chcą w takiej sytuacji jest czymś więcej jak GNUparted
, który zaakceptuje pojedyncze polecenia jakparted /dev/sdb mklabel gpt
. Dzięki temu skrypt może obsługiwać błędy krok po kroku.Co to wszystko ma wspólnego z „wszystko jest plikiem”? Łatwość: potoki zamieniają we / wy program wiersza poleceń w „pliki”. Rury są strumieniami jednokierunkowymi , nie mają dostępu losowego jak zwykły plik na dysku, ale w wielu przypadkach różnica nie ma znaczenia. Ważne jest to, że możesz dołączyć dwa niezależnie opracowane programy i sprawić, by komunikowały się za pomocą prostego tekstu. W tym sensie mogą komunikować się dowolne dwa programy zaprojektowane z myślą o Uniksie .
W przypadkach, w których naprawdę potrzebujesz pliku, łatwo jest przekształcić dane wyjściowe programu w plik:
Ale po co zapisywać dane wyjściowe w pliku tymczasowym, skoro filozofia „wszystko jest plikiem” daje lepszy sposób? Jeśli wszystko, co chcesz zrobić, to wczytać dane wyjściowe tej komendy do
vi
bufora edytora,vi
możesz to zrobić bezpośrednio. W trybievi
„normalnym” powiedz:To wstawia dane wyjściowe tego programu do aktywnego bufora edytora w bieżącej pozycji kursora. Pod maską
vi
używa potoków, aby połączyć wyjście programu z bitem kodu, który używa tych samych wywołań systemu operacyjnego, których użyłby do odczytu z pliku. Nie zdziwiłbym się, gdyby dwa przypadki:r
- to znaczy z i bez!
- oba korzystały z tej samej ogólnej pętli odczytu danych we wszystkich typowych implementacjachvi
. Nie mogę wymyślić dobrego powodu, aby tego nie robić.To też nie jest ostatnia cecha
vi
; wraca do starożytnegoed(1)
edytora tekstuTen potężny pomysł pojawia się wielokrotnie w Uniksie.
Jako drugi przykład tego przywołaj moje
mutt
polecenie e-mail powyżej. Jedynym powodem, dla którego musiałem napisać to jako dwie osobne komendy, jest to, że chciałem nazwać plik tymczasowy*.gz
, aby załącznik e-mail był poprawnie nazwany. Gdybym nie dbał o nazwę pliku, mógłbym użyć podstawienia procesu, aby uniknąć utworzenia pliku tymczasowego:Pozwala to uniknąć tymczasowości, przekształcając dane wyjściowe
gzip -c
w plik FIFO (podobny do pliku) lub/dev/fd
obiekt (podobny do pliku). (Bash wybiera metodę w oparciu o możliwości systemu, ponieważ/dev/fd
nie jest dostępna wszędzie).Po raz trzeci ten potężny pomysł pojawia się w Uniksie, rozważmy
gdb
w systemach Linux. Jest to debugger używany w każdym oprogramowaniu napisanym w C i C ++. Programiści przybywający do Unixa z innych systemów patrzą na togdb
i prawie niezmiennie się nią zajmują: „Fuj, to takie prymitywne!” Następnie szukają debugera GUI, znajdują jeden z kilku istniejących i z radością kontynuują pracę ... często nie zdając sobie sprawy, że GUI po prostu działagdb
pod spodem, zapewniając ładną powłokę. W większości systemów uniksowych nie ma konkurencyjnych debuggerów niskiego poziomu, ponieważ programy nie muszą konkurować na tym poziomie. Potrzebujemy tylko jednego dobrego narzędzia niskiego poziomu, na którym wszyscy możemy oprzeć nasze narzędzia wysokiego poziomu, jeśli to narzędzie niskiego poziomu łatwo komunikuje się za pośrednictwem rur.Oznacza to, że mamy teraz udokumentowany interfejs debuggera, który umożliwiłby zastąpienie drop-in
gdb
, ale niestety główny konkurentgdb
nie wybrał ścieżki o niskim współczynniku tarcia .Nadal jednak możliwe jest, że niektóre przyszłe
gdb
zamiany wpadną w sposób przezroczysty po prostu poprzez klonowanie interfejsu wiersza poleceń. Aby wyciągnąć to samo z Windowsa, twórcy wymiennego narzędzia musieliby zdefiniować formalną wtyczkę lub API automatyzacji. Oznacza to, że tak się nie dzieje, z wyjątkiem najbardziej popularnych programów, ponieważ zbudowanie zarówno zwykłego interfejsu użytkownika wiersza poleceń, jak i pełnego interfejsu API programowania jest bardzo pracochłonne.Ta magia dzieje się dzięki łasce wszechobecnego IPC opartego na tekście .
Chociaż jądro systemu Windows ma anonimowe potoki w stylu uniksowym , rzadko widuje się, że normalne programy użytkownika używają ich do IPC poza powłoką poleceń, ponieważ system Windows nie ma tradycji tworzenia wszystkich podstawowych usług w wersji wiersza poleceń, a następnie budowania GUI na na górze osobno. Prowadzi to do niemożności robienia pewnych rzeczy bez GUI, co jest jednym z powodów, dla których istnieje tak wiele systemów zdalnego pulpitu dla Windows, w porównaniu do Linuksa: Windows jest bardzo trudny w użyciu bez GUI.
Natomiast zdalne administrowanie urządzeniami Unix, BSD, OS X i Linux zdalnie odbywa się za pośrednictwem SSH. A jak to działa, pytasz? SSH łączy gniazdo sieciowe (podobne do pliku) z pseudo tty w
/dev/pty*
(podobnym do pliku). Teraz twój zdalny system jest podłączony do twojego lokalnego poprzez połączenie, które tak płynnie pasuje do Uniksowego sposobu, że możesz przesyłać dane przez połączenie SSH , jeśli to konieczne.Czy zastanawiasz się, jak potężna jest teraz ta koncepcja?
Strumieniowy strumień tekstowy jest nie do odróżnienia z pliku z perspektywy programu, z wyjątkiem tego, że jest jednokierunkowy. Program czyta z potoku w taki sam sposób, jak czyta z pliku: poprzez deskryptor pliku . FD są absolutnie kluczowe dla Uniksa; fakt, że pliki i potoki używają tej samej abstrakcji dla I / O na obu, powinien ci coś powiedzieć
Świat Windows, pozbawiony tradycji prostej komunikacji tekstowej, radzi sobie z ciężkimi interfejsami OOP za pośrednictwem COM lub .NET . Jeśli chcesz zautomatyzować taki program, musisz także napisać program COM lub .NET. Jest to o wiele trudniejsze niż ustawienie potoku na pudełku uniksowym.
Programy systemu Windows pozbawione tych skomplikowanych interfejsów API programowania mogą komunikować się tylko przez zubożałe interfejsy, takie jak schowek lub File / Save, a następnie File / Open.
Długa odpowiedź, część 3: Rejestr a pliki konfiguracyjne
Praktyczna różnica między rejestrem systemu Windows a uniksowym sposobem konfiguracji systemu ilustruje również zalety filozofii „wszystko jest plikiem”.
W systemach typu Unix mogę przeglądać informacje o konfiguracji systemu z wiersza poleceń, po prostu sprawdzając pliki. Mogę zmienić zachowanie systemu, modyfikując te same pliki. W większości te pliki konfiguracyjne są zwykłymi plikami tekstowymi, co oznacza, że mogę używać dowolnego narzędzia w systemie Unix do manipulowania nimi, które mogą pracować z plikami zwykłego tekstu.
Skrypty rejestru nie są prawie tak łatwe w systemie Windows.
Najłatwiejszą metodą jest wprowadzenie zmian za pomocą interfejsu GUI Edytora rejestru na jednym komputerze, a następnie na ślepo zastosowanie tych zmian do innych komputerów za
regedit
pomocą*.reg
plików . To nie jest tak naprawdę „skryptowanie”, ponieważ nie pozwala ci robić niczego warunkowo: to wszystko albo nic.Jeśli zmiany w rejestrze wymagają jakiejkolwiek logiki, następną najłatwiejszą opcją jest nauka programu PowerShell , co w zasadzie oznacza naukę programowania systemu .NET. To tak, jakby Unix posiadał tylko Perla i musiałeś za jego pośrednictwem wykonywać całą administrację systemu ad hoc . Teraz jestem fanem Perla, ale nie wszyscy są. Unix pozwala używać dowolnego narzędzia, które ci się podoba, pod warunkiem, że może ono manipulować zwykłymi plikami tekstowymi.
Przypisy:
Plan 9 stałe tej konstrukcji fałszywy krok, odsłaniając sieci / wy za pośrednictwem na
/net
wirtualnym plików .Bash ma funkcję o nazwie,
/dev/tcp
która umożliwia sieciowe operacje we / wy za pośrednictwem zwykłych funkcji systemu plików. Ponieważ jest to funkcja Bash, a raczej jądro, nie jest widoczna poza Bash ani w systemach, które w ogóle nie używają Bash . Pokazuje to na przykładzie, dlaczego tak dobrym pomysłem jest, aby wszystkie zasoby danych były widoczne przez system plików.Przez „nowoczesny system Windows” rozumiem system Windows NT i wszystkich jego bezpośrednich potomków, w tym Windows 2000, wszystkie wersje systemu Windows Server i wszystkie wersje systemu Windows dla komputerów stacjonarnych od XP. Używam tego terminu, aby wykluczyć wersje systemu Windows oparte na DOS, będące Windows 95 i jego bezpośrednimi potomkami, Windows 98 i Windows ME, a także ich 16-bitowymi poprzednikami.
Rozróżnienie można zobaczyć przez brak jednolitego systemu I / O w tych ostatnich systemach operacyjnych. Nie można przekazać gniazda TCP / IP do
ReadFile()
systemu Windows 95; możesz przesyłać tylko gniazda do interfejsów API Windows Sockets. Zobacz przełomowy artykuł Andrew Schulmana, Windows 95: Czego nie jest, aby głębiej zagłębić się w ten temat.Nie popełnij błędu,
/dev/null
to prawdziwe urządzenie jądra w systemach typu Unix, a nie tylko nazwa pliku w specjalnej obudowie, podobnie jakNUL
w Windowsie.Chociaż system Windows próbuje uniemożliwić utworzenie
NUL
pliku, można ominąć tę ochronę za pomocą zwykłych sztuczek , oszukując logikę analizy nazw plików systemu Windows. Jeśli spróbujesz uzyskać dostęp do tego pliku za pomocącmd.exe
lub Eksploratora, system Windows odmówi otwarcia go, ale możesz napisać do niego za pomocą Cygwin, ponieważ otwiera pliki przy użyciu metod podobnych do programu przykładowego i możesz go usunąć za pomocą podobnych sztuczek .Z drugiej strony, Unix z przyjemnością pozwoli ci
rm /dev/null
, o ile masz dostęp do zapisu/dev
, i pozwoli ci odtworzyć nowy plik na swoim miejscu, wszystko to bez żadnych problemów, ponieważ ten węzeł deweloperski jest po prostu innym plikiem. Chociaż brakuje tego węzła deweloperskiego, zerowe urządzenie jądra nadal istnieje; jest po prostu niedostępny, dopóki nie odtworzysz węzła deweloperskiego za pośrednictwemmknod
.Możesz nawet utworzyć dodatkowe węzły deweloperskie urządzenia zerowego w innym miejscu: nie ma znaczenia, czy je nazwiesz
/home/grandma/Recycle Bin
, dopóki jest to węzeł deweloperski dla urządzenia zerowego, będzie działał dokładnie tak samo jak/dev/null
.W systemie Windows istnieją dwa interfejsy API „formatu dysku” wysokiego poziomu:
SHFormatDrive()
iWin32_Volume.Format()
.Są dwa z bardzo ... cóż ... Windowsowego powodu. Pierwszy z nich prosi Eksploratora Windows o wyświetlenie jego normalnego okna dialogowego „Formatuj dysk”, co oznacza, że działa on na dowolnej nowoczesnej wersji systemu Windows, ale tylko wtedy, gdy użytkownik jest zalogowany interaktywnie. Drugi można wywołać w tle bez udziału użytkownika, ale nie został dodany do systemu Windows aż do Windows Server 2003. To prawda, podstawowe zachowanie systemu operacyjnego było ukryte za GUI do 2003 roku, w świecie, w którym Unix był dostarczany
mkfs
od pierwszego dnia .Moja kopia systemu Unix V5 z 1974 r. Zawiera
/etc/mkfs
4136 bajtowy statycznie powiązany plik wykonywalny PDP-11 . (Unix nie otrzymał dynamicznego połączenia aż do późnych lat 80. , więc nie jest tak, że gdzieś indziej duża biblioteka wykonuje całą prawdziwą robotę.) Jej kod źródłowy - zawarty w obrazie systemu V5 jako/usr/source/s2/mkfs.c
- jest całkowicie samodzielnym 457- program linii C. Nie ma nawet żadnych#include
oświadczeń!Oznacza to, że możesz nie tylko badać, co
mkfs
robi na wysokim poziomie, ale możesz eksperymentować z nim przy użyciu tego samego zestawu narzędzi, z którym utworzono Unix, podobnie jak ty Ken Thompson , cztery dekady temu. Wypróbuj to w systemie Windows. Najbliżej dzisiaj możesz pobrać kod źródłowy DOS , po raz pierwszy wydany w 2014 r. , Który stanowi zaledwie stos źródeł asemblera . Będzie budować tylko przy użyciu przestarzałych narzędzi, których prawdopodobnie nie będziesz mieć pod ręką, a na końcu otrzymasz własną kopię DOS 2.0, systemu operacyjnego znacznie mniej wydajnego niż Unix V5 z 1974 r. , Mimo że został wydany prawie dekadę później.(Po co mówić o Unixie V5? Ponieważ jest to najwcześniejszy kompletny dostępny system uniksowy. Wcześniejsze wersje najwyraźniej straciły czas . Był projekt, który poskładał system uniksowy z czasów V1 / V2, ale wydaje się
mkfs
, że go brakuje , pomimo istnienia strony podręcznika V1, do której odsyłam powyżej, udowadniając, że gdzieś musi istnieć. Albo osoby składające ten projekt nie mogą znaleźć istniejącej kopiimkfs
do włączenia, albo mam ochotę znaleźć pliki, bezfind(1)
których nie ma również tego systemu .:)
)Teraz możesz myśleć: „Czy nie mogę tak po prostu zadzwonić
format.com
? Czy to nie to samo w systemie Windows, co w systemiemkfs
Unix?” Niestety, nie, to nie to samo, z wielu powodów:Po pierwsze,
format.com
nie został zaprojektowany do skryptowania. Wyświetla monit o „naciśnięcie klawisza ENTER, gdy jest gotowy”, co oznacza, że musisz wysłać klawisz Enter do wejścia lub po prostu się zawiesi.Następnie, jeśli chcesz czegoś więcej niż kod statusu powodzenia / niepowodzenia, musisz otworzyć jego standardowe wyjście do odczytu, co jest o wiele bardziej skomplikowane w systemie Windows niż powinno być . (W systemie Unix wszystko w tym linkowanym artykule można wykonać za pomocą prostego
popen(3)
wywołania.)Po przejściu całej tej komplikacji, wynik
format.com
jest trudniejszy do przeanalizowania dla programów komputerowych niż wyjściemkfs
, przeznaczone głównie do spożycia przez ludzi.Jeśli prześledzić to, co
format.com
robi, można zauważyć, że to robi kilka skomplikowanych połączeń doDeviceIoControl()
,ufat.dll
i takie. To nie jest po prostu otwarcie pliku urządzenia i zapisanie nowego systemu plików na tym urządzeniu. Tego rodzaju projekt otrzymujesz od firmy, która zatrudnia 126 000 osób i musi je nadal zatrudniać.Mówiąc o urządzeniach pętlowych, mówię tylko o Linuksie, a nie o Uniksie, ponieważ urządzenia pętlowe nie są przenośne między systemami typu Unix. Istnieją podobne mechanizmy w OS X, BSD itp., Ale składnia jest nieco inna .
W czasach, gdy dyski były wielkości pralek i kosztowały więcej niż luksusowy samochód szefa działu, duże laboratoria komputerowe dzieliłyby większą część swojej łącznej przestrzeni dyskowej w porównaniu do nowoczesnych środowisk komputerowych. Możliwość przezroczystego zaszczepienia dysku zdalnego w lokalnym systemie plików znacznie ułatwiła korzystanie z takich systemów rozproszonych.
/usr/share
Na przykład do tego dochodzimy .W przeciwieństwie do systemu Windows, w którym dysk zdalny jest zwykle albo mapowany na literę dysku, albo musi być dostępny poprzez ścieżkę UNC, a nie zintegrowany z lokalnym systemem plików. Litery napędowe oferują niewiele możliwości wyrażenia symbolicznego; nie
P:
odnoszą się do „przestrzeni publicznej” na BigServer, albo „pakiety” katalogu na serwerze lustrzanym oprogramowanie? Ścieżki UNC oznaczają, że musisz pamiętać, na którym serwerze znajdują się Twoje zdalne pliki, co staje się trudne w dużej organizacji z setkami lub tysiącami serwerów plików.Windows nie pojawił się dowiązań symbolicznych, dopóki system Windows Vista, wydany w 2007 roku, który wprowadził dowiązania symboliczne NTFS . Dowiązania symboliczne systemu Windows są nieco bardziej wydajne niż dowiązania symboliczne systemu Unix - cecha systemu Unix od 1977 r. - ponieważ mogą wskazywać również na zdalny udział plików, a nie tylko na ścieżkę lokalną. Unix zrobił to inaczej, poprzez NFS w 1984 r. , Który opiera się na istniejącej wcześniej uniksowej opcji montowania , którą miał od samego początku.
Tak więc, w zależności od tego, jak na to patrzysz, Windows podążał za Unixem przez około 2-3 dekady.
Nawet wtedy dowiązania symboliczne nie są normalną częścią doświadczenia użytkownika systemu Windows z kilku powodów.
Po pierwsze, można je tworzyć tylko za pomocą programu wiersza polecenia wstecz
MKLINK
. Nie można tworzyć je z Eksploratora Windows, natomiast odpowiedniki Unix Windows Explorer zazwyczaj nie pozwalają tworzyć dowiązania.Po drugie, domyślna konfiguracja systemu Windows uniemożliwia zwykłym użytkownikom tworzenie dowiązań symbolicznych, wymagając, abyś albo uruchomił powłokę poleceń jako Administrator, albo zezwolił użytkownikowi na ich utworzenie za pomocą niejasnej ścieżki w narzędziu, którego przeciętny użytkownik nawet nie widział, a tym bardziej nie wie jak używać. (W przeciwieństwie do większości problemów z uprawnieniami administratora w systemie Windows, Kontrola konta użytkownika nie jest w tym przypadku pomocna.)
Linux-y nie zawsze używają obrazu dysku wirtualnego w sekwencji rozruchowej. Istnieje wiele różnych sposobów, aby to zrobić .
man ed
Nawiasem mówiąc, deskryptory gniazd sieciowych to także FD.
źródło
/proc/registry
pseudo-systemu plików w systemie MS Windows.Jeśli wziąć pod uwagę
Linux
, jak język angielski ,file systems
są alfabetów , które są zasadniczo takie bloki fundamentowe dla języka angielskiego .Ze strony wiki systemu plików,
Tak więc w laickich terminach bez odpowiedniej struktury językowej dla języka angielskiego (który składa się z alfabetów), interakcja człowieka nie miałaby żadnego znaczenia. Podobnie bez systemów plików jakiekolwiek dane, które mamy w bazowym urządzeniu magazynującym, nie będą miały rzeczywistego znaczenia.
źródło