Windows – laické vysvětlení pro „všechno je soubor“ – co se liší od Windows?

Vím, že „Všechno je soubor“ znamená, že i zařízení mají svůj název souboru a cestu v systémech Unix a Unixu podobných, a že to umožňuje použití běžných nástrojů na různých zdrojích bez ohledu na jejich povahu. Ale nemohu to přirovnat k Windows, jedinému jinému OS, se kterým jsem pracoval. Četl jsem nějaké články o tomto konceptu, ale myslím, že jsou pro nevývojáře poněkud nesnadné na uchopení. Lidé potřebují laické vysvětlení!

Například, když chci zkopírovat soubor na CF kartu, která je připojena ke čtečce karet, použiji něco jako

zcat name_of_file > /dev/sdb

Myslím, že ve Windows se čtečka karet objeví jako ovladač a my uděláme něco podobného, ​​myslím. Jak se tedy liší filozofie „Všechno je soubor“?

Přijatá odpověď:

„Všechno je soubor“ je trochu libové. „Všechno se objeví někde v souborovém systému“ je blíže značce, a i tak je to spíše ideál než zákon návrhu systému.

Například sokety domén Unix nejsou soubory, ale objevují se v souborovém systému. Můžete ls -l doménový soket pro zobrazení jeho atributů, upravte jeho řízení přístupu pomocí chmod a na některých systémech typu Unix (např. macOS, ale ne Linux) můžete dokonce cat data do/z jednoho.

Ale i když jsou běžné síťové sokety TCP/IP vytvářeny a manipulovány se stejnými systémovými voláními soketů BSD jako sokety domén Unix, sokety TCP/IP to ne zobrazí se v souborovém systému,¹ i když neexistuje žádný zvlášť dobrý důvod, proč by to měla být pravda.

Dalším příkladem nesouborových objektů objevujících se v souborovém systému je Linux /proc souborový systém. Tato funkce zpřístupňuje uživatelskému prostoru velké množství podrobností o běhu jádra, většinou jako virtuální prosté textové soubory. Mnoho /proc položky jsou pouze pro čtení, ale hodně /proc je také zapisovatelný, takže můžete změnit způsob, jakým systém běží pomocí libovolného programu, který dokáže upravit soubor. Bohužel, opět tu máme neideálnost:Unixy typu BSD obecně běží bez /proc a Unixy System V odhalují mnohem méně prostřednictvím /proc než Linux.

Nemohu to přirovnat k MS Windows

Zaprvé, velká část sentimentu, který můžete najít na internetu a v knihách o Unixu, který se týká pouze I/O souborů a Windows jsou v tomto ohledu „rozbité“, je zastaralá. Windows NT toho hodně opravil.

Moderní verze Windows mají jednotný I/O systém, stejně jako Unix, takže můžete číst síťová data ze soketu TCP/IP pomocí ReadFile() spíše než rozhraní API specifické pro Windows Sockets WSARecv() , Pokud chceš. To přesně odpovídá Unixovému způsobu, kde můžete číst ze síťového soketu buď obecným read(2) Unixové systémové volání nebo recv(2) specifické pro sockety zavolejte.²

Přesto se Windows stále nedaří pozvednout tento koncept na stejnou úroveň jako Unix, a to ani zde v roce 2021. Existuje mnoho oblastí architektury Windows, ke kterým nelze přistupovat prostřednictvím souborového systému nebo na ně nelze nahlížet jako na soubor. Několik příkladů:

1. Ovladače.

Subsystém ovladačů pro Windows je snadno stejně bohatý a výkonný jako Unix, ale k psaní programů pro manipulaci s ovladači musíte obecně použít Windows Driver Kit, což znamená psaní kódu C nebo .NET.

Na operačních systémech typu Unix můžete s ovladači udělat hodně z příkazového řádku. Téměř jistě jste to již udělali, i když pouze přesměrováním nechtěného výstupu na /dev/null .³

2. Komunikace mezi programy.

Programy Windows spolu nekomunikují snadno.

Unixové programy příkazového řádku snadno komunikují prostřednictvím textových proudů a kanálů. Programy GUI jsou často buď postaveny nad programy příkazového řádku, nebo exportují rozhraní textových příkazů, takže stejné jednoduché mechanismy textové komunikace fungují také s programy GUI.

3. Registr.

Unix nemá žádný přímý ekvivalent registru Windows. Stejné informace jsou rozptýleny v souborovém systému, většina z nich v /etc , /proc a /sys .

Pokud nevidíte, že ovladače, kanály a odpovědi Unixu na registr Windows mají co do činění s „všechno je soubor“, čtěte dále.

Jak se zde liší filozofie „Všechno je soubor“?

Vysvětlím to podrobně rozvedením mých tří výše uvedených bodů.

Dlouhá odpověď, část 1:Disky vs. soubory zařízení

Řekněme, že se vaše čtečka karet CF zobrazuje jako E: pod Windows a /dev/sdc pod Linuxem. Jaký je v tom praktický rozdíl?

Není to jen malý rozdíl v syntaxi.

V Linuxu mohu říci dd if=/dev/zero of=/dev/sdc pro přepsání obsahu /dev/sdc s nulami.

Zamyslete se na chvíli nad tím, co to znamená. Zde mám normální program pro uživatelský prostor (dd(1) ), které jsem požádal o načtení dat z virtuálního zařízení (/dev/zero ) a zapsat to, co přečetl, do skutečného fyzického zařízení (/dev/sdc ) prostřednictvím jednotného souborového systému Unix. dd neví, že čte ze speciálních zařízení a zapisuje do nich. Bude fungovat stejně dobře na běžných souborech nebo na kombinaci zařízení a souborů, jak uvidíme níže.

Neexistuje snadný způsob, jak vynulovat E: drive v systému Windows, protože systém Windows rozlišuje mezi soubory a jednotkami, takže k manipulaci s nimi nemůžete používat stejné příkazy. Nejblíže se můžete dostat k formátování disku bez možnosti Rychlé formátování, která nejvíce nuluje obsahu disku, ale pak na něj zapíše nový souborový systém. Co když nechci nový souborový systém? Co když opravdu chci, aby byl disk zaplněn pouze nulami?

Buďme velkorysí a řekněme, že opravdu chceme nový souborový systém na E: . Abych to mohl udělat v programu ve Windows, musím zavolat speciální formátovací API.⁴ V Linuxu nemusíte psát program, abyste získali přístup k funkci „formátování disku“ operačního systému. Stačí spustit příslušný program uživatelského prostoru pro typ souborového systému, který chcete vytvořit:mkfs.ext4 , mkfs.xfs , nebo co máš. Tyto programy zapíší souborový systém do jakéhokoli souboru nebo /dev uzel, který předáte.

Protože mkfs programy typu na Unixy systémech pracují se soubory bez umělých rozdílů mezi zařízeními a normálními soubory, to znamená, že mohu vytvořit souborový systém ext4 v normálním souboru na mém Linuxu:

$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs

To doslova vytvoří obraz disku o velikosti 1 MiB v aktuálním adresáři, nazvaný myfs . Poté jej mohu připojit, jako by to byl jakýkoli jiný externí souborový systém:

$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint

Nyní mám obraz disku ext4 se souborem nazvaným my-passwd-entry v něm, který obsahuje /etc/passwd mého uživatele vstup.

Pokud chci, můžu ten obrázek přenést na svou CF kartu:

$ sudo dd if=myfs of=/dev/sdc1

Nebo mohu zabalit obraz disku, poslat vám jej poštou a nechat vás jej zapsat na médium vaše výběr, jako je USB flash disk:

$ gzip myfs
$ echo "Here's the disk image I promised to send you." | 
  mutt -a myfs.gz -s "Password file disk image" [email protected]

To vše je na Linuxu možné⁵, protože neexistuje žádný umělý rozdíl mezi soubory, souborovými systémy a zařízeními. Mnoho věcí na unixových systémech buď je soubory nebo jsou přístupné prostřednictvím souborového systému, takže vypadají soubory nebo nějakým jiným způsobem vypadají dostatečně jako soubory, aby se s nimi dalo zacházet.

Koncepce souborového systému ve Windows je špinavá; rozlišuje mezi adresáři, jednotkami a síťovými prostředky. Existují tři různé syntaxe, všechny smíchané ve Windows:Unix-like ..FOOBAR systém cesty, písmena jednotek jako C: a cesty UNC jako \SERVERPATHFILE.TXT . Je to proto, že jde spíše o narůstání nápadů z Unixu, CP/M, MS-DOS a LAN Manageru, než o jeden koherentní návrh. To je důvod, proč je v názvech souborů Windows tolik nepovolených znaků.

Unix má jednotný souborový systém se vším přístupným pomocí jediného společného schématu. Pro program běžící na Linuxu neexistuje žádný funkční rozdíl mezi /etc/passwd , /media/CF_CARD/etc/passwd a /mnt/server/etc/passwd . S místními soubory, externími médii a sdílenými síťovými položkami se zachází stejným způsobem.⁶

Windows mohou dosáhnout podobných cílů jako můj příklad obrazu disku výše, ale musíte použít speciální programy napsané neobyčejně talentovanými programátory. To je důvod, proč je v systému Windows tolik programů typu „virtuální DVD“. Absence základní funkce operačního systému vytvořila umělý trh pro programy, které by zaplnily mezeru, což znamená, že máte spoustu lidí, kteří soutěží o vytvoření nejlepšího programu typu virtuální DVD. Na systémech *ix takové programy nepotřebujeme, protože můžeme pouze připojit obraz disku ISO pomocí smyčkového zařízení.

Související:Jak zabránit RealVNC ve změně měřítka zobrazení na základě možnosti změny měřítka systému Windows?

Totéž platí pro další nástroje, jako jsou programy pro mazání disku, které na unixových systémech také nepotřebujeme. Chcete, aby byl obsah vaší CF karty nenávratně zakódován namísto pouhého vynulování? Dobře, použijte /dev/random jako zdroj dat namísto /dev/zero :

$ sudo dd if=/dev/random of=/dev/sdc

V Linuxu taková kola nevynalézáme, protože základní funkce OS nejen fungují dostatečně dobře, ale fungují tak dobře, že jsou všudypřítomné. Typické schéma pro spouštění linuxového boxu zahrnuje virtuální diskový obraz, například pouze jeden příklad, vytvořený pomocí technik, které jsou uvedeny výše.⁷

Cítím, že je správné poukázat na to, že kdyby Unix od začátku integroval TCP/IP I/O do souborového systému, neměli bychom netcat vs socat vs Ncat vs nc nepořádek, jehož příčinou byla stejná konstrukční slabina, která vedla k rozšíření nástrojů pro imaging a mazání disku ve Windows:nedostatek přijatelného OS.

Dlouhá odpověď, část 2:Trubky jako virtuální soubory

Navzdory svým kořenům v DOSu neměl Windows nikdy bohatou tradici příkazového řádku.

To neznamená, že systém Windows nemá příkazový řádek nebo že postrádá mnoho programů příkazového řádku. Windows má v dnešní době dokonce velmi výkonný příkazový shell, vhodně nazvaný PowerShell.

Tento nedostatek tradice příkazového řádku má však vedlejší účinky. Získáte nástroje jako DISKPART což je ve světě Windows téměř neznámé, protože většina lidí dělá rozdělení disku a podobně pomocí modulu snap-in Správa počítače MMC. Když pak potřebujete skriptovat vytváření oddílů, zjistíte, že DISKPART nebyl ve skutečnosti vytvořen tak, aby byl řízen jiným programem. Ano, můžete zapsat řadu příkazů do souboru skriptu a spustit jej pomocí DISKPART /S scriptfile , ale je to všechno nebo nic. Co skutečně chtít je v takové situaci něco jako GNU parted , který bude přijímat jednotlivé příkazy jako parted /dev/sdb mklabel gpt . To umožňuje vašemu skriptu provádět zpracování chyb krok za krokem.

Co to všechno má společného s „všechno je soubor“? Snadné:roury dělají z programu příkazového řádku I/O do svého druhu „soubory“. Pipe jsou jednosměrné toky, nemají náhodný přístup jako běžný diskový soubor, ale v mnoha případech je rozdíl bezvýznamný. Důležité je, že můžete připojit dva nezávisle vyvinuté programy a přimět je komunikovat prostřednictvím jednoduchého textu. V tomto smyslu mohou komunikovat jakékoli dva programy navržené s ohledem na Unixovou cestu.

V případech, kdy opravdu potřebujete soubor, je snadné převést výstup programu na soubor:

$ some-program --some --args > myfile
$ vi myfile

Proč ale zapisovat výstup do dočasného souboru, když filozofie „všechno je soubor“ vám nabízí lepší způsob? Pokud vše, co chcete udělat, je načíst výstup tohoto příkazu do vi vyrovnávací paměť editoru, vi může to udělat přímo za vás. Z vi „normální“ režim, řekněte:

:r !some-program --some --args

Tím se výstup tohoto programu vloží do aktivní vyrovnávací paměti editoru na aktuální pozici kurzoru. Pod kapotou vi používá roury k připojení výstupu programu k kousku kódu, který používá stejná volání OS, která by místo toho použila ke čtení ze souboru. Nepřekvapilo by mě, kdyby dva případy :r — tedy s a bez ! — oba používaly stejnou obecnou smyčku čtení dat ve všech běžných implementacích vi . Nenapadá mě dobrý důvod, proč to neudělat.

Toto není nejnovější funkce vi , buď; to sahá až do starověkého ed(1) textový editor.⁸

Tato mocná myšlenka se v Unixu objevuje znovu a znovu.

Jako druhý příklad si vzpomeňte na můj mutt příkaz email výše. Jediný důvod, proč jsem to musel napsat jako dva samostatné příkazy je, že jsem chtěl, aby se dočasný soubor jmenoval *.gz , aby byla příloha e-mailu správně pojmenována. Kdyby mi na názvu souboru nezáleželo, mohl jsem použít substituci procesu, abych se vyhnul vytvoření dočasného souboru:

$ echo "Here's the disk image I promised to send you." | 
  mutt -a <(gzip -c myfs) -s "Password file disk image" [email protected]

Tím se zabrání dočasnému otočením výstupu gzip -c do FIFO (což je jako soubor) nebo /dev/fd objekt (který je podobný souboru). (Bash volí metodu na základě schopností systému, protože /dev/fd není k dispozici všude.)

Ještě třetí způsob, jak se tato mocná myšlenka objevuje v Unixu, zvažte gdb na systémech Linux. Toto je debugger používaný pro jakýkoli software napsaný v C a C++. Programátoři přicházející na Unix z jiných systémů se dívají na gdb a téměř vždy nad tím naříkat:"Fuj, to je tak primitivní!" Pak jdou hledat GUI debugger, najdou jeden z několika, které existují, a šťastně pokračují ve své práci… často si nikdy neuvědomují, že GUI prostě běží gdb zespodu a navrchu poskytuje hezkou skořápku. Na většině unixových systémů neexistují konkurenční nízkoúrovňové debuggery, protože není potřeba, aby na této úrovni soutěžily programy. Vše, co potřebujeme, je jeden dobrý nízkoúrovňový nástroj, na kterém můžeme všichni založit naše nástroje na vysoké úrovni, pokud tento nízkoúrovňový nástroj snadno komunikuje prostřednictvím potrubí.

To znamená, že nyní máme zdokumentované rozhraní ladicího programu, které by umožnilo výměnu gdb pomocí drop-in , ale bohužel je primárním konkurentem gdb nevydal cestu s nízkým třením.

Přesto je to přinejmenším možné že nějaké budoucí gdb nahrazení by transparentně zapadlo jednoduše klonováním jeho rozhraní příkazového řádku. Aby bylo možné vytáhnout totéž na krabici s Windows, museli by tvůrci vyměnitelného nástroje definovat nějaký formální plugin nebo automatizační API. To znamená, že k tomu nedochází s výjimkou těch nejpopulárnějších programů, protože vytvořit jak běžné uživatelské rozhraní příkazového řádku, tak kompletní programovací API je hodně práce.

Toto kouzlo se děje díky všudypřítomnému textovému IPC.

Ačkoli jádro Windows má anonymní kanály ve stylu Unixu, je vzácné vidět, že je běžné uživatelské programy používají pro IPC mimo příkazový shell, protože Windows postrádá tuto tradici vytvářet všechny základní služby nejprve ve verzi s příkazovým řádkem a poté na něm stavět GUI. v horní části samostatně. To vede k nemožnosti dělat některé věci bez GUI, což je jeden z důvodů, proč existuje tolik systémů vzdálené plochy pro Windows ve srovnání s Linuxem:Windows se bez GUI velmi těžko používají.

Naproti tomu je běžné vzdáleně spravovat boxy Unix, BSD, OS X a Linux vzdáleně přes SSH. A jak to funguje, ptáte se? SSH připojuje síťový soket (který je podobný souboru) k pseudo tty na /dev/pty* (což je jako soubor). Nyní je váš vzdálený systém připojen k vašemu místnímu prostřednictvím připojení, které se tak hladce shoduje s Unixovým způsobem, že v případě potřeby můžete data přenášet přes připojení SSH.

Máte představu o tom, jak mocný je tento koncept nyní?

Datový textový proud je z pohledu programu k nerozeznání od souboru, kromě toho, že je jednosměrný. Program čte z roury stejným způsobem, jakým čte ze souboru:prostřednictvím deskriptoru souboru. FD jsou absolutní jádro Unixu; Skutečnost, že soubory a kanály používají stejnou abstrakci pro I/O na obou, by vám měla něco napovědět.⁹

Svět Windows, kterému chybí tato tradice jednoduché textové komunikace, si vystačí s těžkými OOP rozhraními přes COM nebo .NET. Pokud potřebujete automatizovat takový program, musíte také napsat program COM nebo .NET. To je o něco obtížnější než nastavení roury na unixovém boxu.

Programy Windows bez těchto komplikovaných programovacích rozhraní API mohou komunikovat pouze prostřednictvím ochuzených rozhraní, jako je schránka nebo Soubor/Uložit a následně Soubor/Otevřít.

Dlouhá odpověď, část 3:Registr vs konfigurační soubory

Praktický rozdíl mezi registrem Windows a Unixovým způsobem konfigurace systému také ilustruje výhody filozofie „všechno je soubor“.

Související:Zabránit automatickému vypnutí hotspotu Wifi systému Windows 10 na 1809?

Na systémech typu Unix se mohu podívat na informace o konfiguraci systému z příkazového řádku pouhým prozkoumáním souborů. Mohu změnit chování systému úpravou stejných souborů. Z velké části jsou tyto konfigurační soubory pouze soubory ve formátu prostého textu, což znamená, že k manipulaci s nimi mohu použít jakýkoli nástroj v Unixu, který dokáže pracovat se soubory ve formátu prostého textu.

Skriptování registru není v systému Windows zdaleka tak snadné.

Nejjednodušší metodou je provést změny prostřednictvím GUI Editoru registru na jednom počítači a poté tyto změny slepě aplikovat na ostatní počítače pomocí regedit přes *.reg soubory. To ve skutečnosti není „skriptování“, protože vám nedovolí dělat nic podmíněně:je to všechno nebo nic.

Pokud změny v registru vyžadují nějaké množství logiky, další nejjednodušší možností je naučit se PowerShell, což v podstatě znamená naučit se programování systému .NET. Bylo by to, jako kdyby měl Unix pouze Perl a vy byste museli dělat vše ad hoc administrace systému přes něj. Teď jsem fanouškem Perlu, ale ne každý. Unix vám umožňuje používat jakýkoli nástroj, který se vám líbí, pokud umí pracovat se soubory ve formátu prostého textu.

Poznámky pod čarou:

1. Plán 9 opravil tuto chybu v návrhu a odhalil síťový vstup/výstup prostřednictvím /net virtuální souborový systém.

Bash má funkci nazvanou /dev/tcp který umožňuje síťové I/O prostřednictvím běžných funkcí souborového systému. Protože se jedná o funkci Bash, spíše o funkci jádra, není viditelná mimo Bash nebo na systémech, které Bash vůbec nepoužívají. To ukazuje na protipříkladu, proč je tak dobrý nápad zviditelnit všechny datové zdroje prostřednictvím souborového systému.

2. Pojmem „moderní Windows“ mám na mysli Windows NT a všechny jeho přímé potomky, což zahrnuje Windows 2000, všechny verze Windows Server a všechny verze Windows pro stolní počítače počínaje XP. Tento termín používám k vyloučení verzí Windows založených na DOSu, což jsou Windows 95 a jeho přímí potomci, Windows 98 a Windows ME, plus jejich 16bitové předchůdce.

Rozdíl můžete vidět tím, že v těchto posledně jmenovaných operačních systémech chybí jednotný I/O systém. Nelze předat soket TCP/IP do ReadFile() na Windows 95; sokety můžete předávat pouze rozhraním API Windows Sockets. Podívejte se na klíčový článek Andrewa Schulmana Windows 95:What It’s Not pro hlubší ponor do tohoto tématu.

3. Nenechte se mýlit, /dev/null je skutečné jádro na systémech typu Unix, nikoli pouze název souboru se speciálními malými písmeny, jako je povrchní ekvivalent NUL ve Windows.

Ačkoli se vám Windows snaží zabránit ve vytvoření NUL soubor, je možné tuto ochranu obejít pouhým trikem, oklamáním logiky analýzy názvů souborů Windows. Pokud se pokusíte získat přístup k tomuto souboru pomocí cmd.exe nebo Průzkumník, Windows jej odmítnou otevřít, ale můžete do něj zapisovat přes Cygwin, protože otevírá soubory podobnými metodami jako ukázkový program a můžete jej smazat podobným trikem.

Naproti tomu Unix vám s radostí umožní rm /dev/null , pokud máte přístup pro zápis do /dev , a umožní vám znovu vytvořit nový soubor na jeho místě, to vše bez triků, protože tento dev uzel je jen další soubor. I když tento vývojový uzel chybí, null zařízení jádra stále existuje; je prostě nepřístupný, dokud znovu nevytvoříte vývojářský uzel pomocí mknod .

Můžete dokonce vytvořit další nulové uzly pro vývoj zařízení jinde:nezáleží na tom, jestli to nazvete /home/grandma/Recycle Bin , pokud je to vývojářský uzel pro null zařízení, bude fungovat úplně stejně jako /dev/null .

4. Ve skutečnosti jsou dva vysokoúrovňová rozhraní API „formát disku“ ve Windows:SHFormatDrive() a Win32_Volume.Format() .

Existují dva pro velmi...dobře...Windows jakýsi důvod. První z nich požádá Průzkumníka Windows, aby zobrazil své normální dialogové okno „Formát disku“, což znamená, že funguje na jakékoli moderní verzi Windows, ale pouze pokud je uživatel interaktivně přihlášen. Druhý můžete volat na pozadí bez zásahu uživatele. ale do Windows nebyl přidán až do Windows Server 2003. Správně, chování jádra OS bylo skryto za GUI až do roku 2003, ve světě, kde Unix dodával mkfs ode dne 1.

Moje kopie Unixu V5 z roku 1974 obsahuje /etc/mkfs , 4136 bajtový staticky propojený spustitelný soubor PDP-11. (Unix získal dynamické propojení až na konci 80. let, takže to není tak, že by existovala velká knihovna někde jinde, která by dělala veškerou skutečnou práci.) Jeho zdrojový kód – součástí obrazu systému V5 jako /usr/source/s2/mkfs.c — je zcela samostatný 457řádkový program C. Nejsou zde ani žádné #include prohlášení!

To znamená, že můžete nejen zkoumat, co mkfs je na vysoké úrovni, můžete s ním experimentovat pomocí stejné sady nástrojů, se kterou byl vytvořen Unix, stejně jako vy jste Ken Thompson před čtyřmi desetiletími. Zkuste to s Windows. Nejbližší, co můžete dnes, je stáhnout si zdrojový kód DOS, který byl poprvé vydán v 2014 , který najdete, představuje pouhou hromadu montážních zdrojů. Bude se stavět pouze se zastaralými nástroji, které pravděpodobně nebudete mít po ruce, a nakonec získáte svou vlastní kopii DOS 2.0, OS mnohem méně výkonného než Unix V5 z roku 1974, přestože byl vydán téměř o deset let později.

(Proč mluvit o Unixu V5? Protože je to nejstarší kompletní unixový systém, který je stále k dispozici. Dřívější verze jsou zjevně ztraceny časem. Existoval projekt, který dal dohromady Unix z éry V1/V2, ale zdá se, že chybí mkfs , navzdory existenci výše odkazované manuálové stránky V1, která dokazuje, že někde musela existovat, někdy. Ti, kdo dávali tento projekt dohromady, nemohli najít existující kopii mkfs zahrnout, nebo jsem se vysával při hledání souborů bez find(1) , který v tomto systému také neexistuje. :) )

Možná si teď říkáte:„Nemohl bych zavolat na format.com? ? Není to ve Windows totéž jako volání mkfs v Unixu?" Bohužel, ne, není to totéž, z mnoha důvodů:

- First, `format.com` wasn't designed to be scripted. It prompts you to "press ENTER when ready", which means you need to send an Enter key to its input, or it'll just hang.

- Then, if you want anything more than a success/failure status code, you have to open its standard output for reading, which is [far more complicated on Windows than it has to be](http://msdn.microsoft.com/en-us/library/windows/desktop/ms682499%28v=vs.85%29.aspx). (On Unix, everything in that linked article can be accomplished with a simple [`popen(3)`](http://linux.die.net/man/3/popen) call.)

- Having gone through all this complication, the output of `format.com` is harder to parse for computer programs than the output of `mkfs`, being intended primarily for human consumption.

- If you trace what `format.com` does, you find that it does a bunch of complicated calls to [`DeviceIoControl()`](http://msdn.microsoft.com/en-us/library/windows/desktop/aa363216%28v=vs.85%29.aspx), `ufat.dll`, and such. It is not simply opening a device file and writing a new filesystem onto that device. This is the sort of design you get from [a company that employs 126000 people](https://news.microsoft.com/facts-about-microsoft/#EmploymentInfo), and needs to *keep* employing them.

5. Když mluvím o smyčkových zařízeních, mluvím pouze o Linuxu spíše než o Unixu obecně, protože smyčková zařízení nejsou přenosná mezi systémy typu Unix. Podobné mechanismy existují v OS X, BSD atd., ale syntaxe se poněkud liší.

6. V dobách, kdy diskové jednotky dosahovaly velikosti praček a byly dražší než luxusní auto vedoucího oddělení, sdílely velké počítačové laboratoře větší část svého společného diskového prostoru ve srovnání s moderními počítačovými prostředími. Schopnost transparentně naroubovat vzdálený disk do místního souborového systému značně zjednodušila používání takových distribuovaných systémů. Zde získáme /usr/share , například.

Na rozdíl od Windows, kde je vzdálený disk obvykle buď namapován na písmeno jednotky, nebo k němu musí být přístup prostřednictvím cesty UNC, spíše než transparentní integrace do místního souborového systému. Písmena disku vám nabízejí několik možností pro symbolické vyjádření; dělá P: odkazovat na „veřejný“ prostor na BigServeru nebo do adresáře „balíčků“ na softwarovém mirror serveru? Cesty UNC znamenají, že si musíte pamatovat, na kterém serveru jsou vaše vzdálené soubory, což je ve velké organizaci se stovkami nebo tisíci souborových serverů obtížné.

Systém Windows nezískal symbolické odkazy, dokud systém Windows Vista, vydaný v roce 2007, zavedl symbolické odkazy NTFS. Symbolické odkazy Windows jsou o něco výkonnější než symbolické odkazy Unixu – funkce Unixu od roku 1977 – v tom, že mohou ukazovat i na vzdálené sdílení souborů, nejen na místní cestu. Unix to udělal jinak, prostřednictvím NFS v roce 1984, které staví na již existující funkci přípojného bodu Unixu, kterou má od začátku.

Související:XML bez LF chcete, aby to bylo hezké pomocí příkazu sed v shellu?

Takže v závislosti na tom, jak se na to podíváte, Windows zaostával za Unixem zhruba o 2 nebo 3 desetiletí.

Ani potom nejsou symbolické odkazy běžnou součástí uživatelského prostředí Windows, a to z několika důvodů.

Za prvé, můžete je vytvořit pouze pomocí zpětného příkazového řádku programu MKLINK . Nemůžete je vytvořit z Průzkumníka Windows, zatímco unixové ekvivalenty Průzkumníka Windows obvykle dělají vám umožní vytvářet symbolické odkazy.

Za druhé, výchozí konfigurace systému Windows brání normálním uživatelům ve vytváření symbolických odkazů, což vyžaduje, abyste buď spustili příkazový shell jako správce, nebo dali uživateli oprávnění k jejich vytvoření prostřednictvím neznámé cesty v nástroji, který váš průměrný uživatel nikdy neviděl, mnohem méně toho ví. jak používat. (A na rozdíl od většiny problémů s oprávněními správce ve Windows, UAC v tomto případě nepomůže.)

7. Linuxové boxy ne vždy používají obraz virtuálního disku v zaváděcí sekvenci. Existuje mnoho různých způsobů, jak to udělat.

8. man ed

9. Mimochodem, deskriptory síťového soketu jsou také FD pod nimi.