Windows:una spiegazione pratica per "tutto è un file": cosa differisce da Windows?

In che modo la filosofia "Tutto è un file" fa la differenza qui?

Lo spiegherò ampliando i miei tre punti sopra, in dettaglio.

Risposta lunga, parte 1:Drive e file del dispositivo

Supponiamo che il tuo lettore di schede CF appaia come E: sotto Windows e /dev/sdc sotto Linux. Che differenza pratica fa?

Non è solo una piccola differenza di sintassi.

Su Linux, posso dire dd if=/dev/zero of=/dev/sdc per sovrascrivere il contenuto di /dev/sdc con zeri.

Pensa per un secondo a cosa significa. Qui ho un normale programma di spazio utente (dd(1) ) in cui ho chiesto di leggere i dati da un dispositivo virtuale (/dev/zero ) e scrivi ciò che ha letto su un dispositivo fisico reale (/dev/sdc ) tramite il filesystem Unix unificato. dd non sa che sta leggendo e scrivendo su dispositivi speciali. Funzionerà altrettanto bene su file normali o su un mix di dispositivi e file, come vedremo di seguito.

Non esiste un modo semplice per azzerare E: drive su Windows, perché Windows fa una distinzione tra file e unità, quindi non puoi usare gli stessi comandi per manipolarli. Il più vicino possibile è eseguire una formattazione del disco senza l'opzione Formattazione rapida, che azzera maggior parte del contenuto dell'unità, ma poi scrive un nuovo filesystem sopra di esso. E se non voglio un nuovo filesystem? E se volessi davvero riempire il disco con nient'altro che zeri?

Siamo generosi e diciamo che vogliamo davvero un nuovo filesystem su E: . Per farlo in un programma su Windows, devo chiamare un'API di formattazione speciale.⁴ Su Linux, non è necessario scrivere un programma per accedere alla funzionalità "formatta disco" del sistema operativo. Esegui semplicemente il programma di spazio utente appropriato per il tipo di filesystem che desideri creare:mkfs.ext4 , mkfs.xfs , o cosa hai. Questi programmi scriveranno un filesystem su qualsiasi file o /dev nodo che superi.

Perché mkfs i programmi di tipo su sistemi Unixy funzionano su file senza fare distinzioni artificiali tra dispositivi e file normali, significa che posso creare un filesystem ext4 all'interno di un file normale sulla mia macchina Linux:

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

Ciò crea letteralmente un'immagine disco da 1 MiB nella directory corrente, chiamata myfs . Posso quindi montarlo come se fosse un qualsiasi altro filesystem esterno:

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

Ora ho un'immagine disco ext4 con un file chiamato my-passwd-entry in esso che contiene il /etc/passwd del mio utente voce.

Se voglio, posso far esplodere quell'immagine sulla mia scheda CF:

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

Oppure posso impacchettare l'immagine del disco, spedirvela per posta e lasciarla scrivere su un supporto tuo scegliendo, ad esempio una chiavetta USB:

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

Tutto questo è possibile su Linux⁵ perché non esiste una distinzione artificiale tra file, filesystem e dispositivi. Molte cose sui sistemi Unix sono o si accede tramite il filesystem in modo che assomiglino file, o in qualche altro modo hanno un aspetto sufficientemente simile a un file da poter essere trattati come tali.

Il concetto di filesystem di Windows è un miscuglio; fa distinzioni tra directory, unità e risorse di rete. Ci sono tre diverse sintassi, tutte fuse insieme in Windows:il ..FOOBAR simile a Unix sistema di percorso, lettere di unità come C: e percorsi UNC come \SERVERPATHFILE.TXT . Questo perché è un accrescimento di idee da Unix, CP/M, MS-DOS e LAN Manager, piuttosto che un unico progetto coerente. È per questo che ci sono così tanti caratteri illegali nei nomi dei file di Windows.

Unix ha un filesystem unificato, con tutto accessibile da un unico schema comune. Per un programma in esecuzione su una macchina Linux, non c'è alcuna differenza funzionale tra /etc/passwd , /media/CF_CARD/etc/passwd e /mnt/server/etc/passwd . I file locali, i media esterni e le condivisioni di rete vengono trattati tutti allo stesso modo.⁶

Windows può raggiungere obiettivi simili al mio esempio di immagine del disco sopra, ma devi usare programmi speciali scritti da programmatori di talento non comune. Questo è il motivo per cui ci sono così tanti programmi di tipo "DVD virtuale" su Windows. La mancanza di una funzionalità di base del sistema operativo ha creato un mercato artificiale per i programmi per colmare il divario, il che significa che hai un gruppo di persone in competizione per creare il miglior programma di tipo DVD virtuale. Non abbiamo bisogno di tali programmi sui sistemi *ix, perché possiamo semplicemente montare un'immagine disco ISO utilizzando un dispositivo loop.

Lo stesso vale per altri strumenti come i programmi di pulizia del disco, di cui non abbiamo bisogno sui sistemi Unix. Vuoi che il contenuto della tua scheda CF venga irrimediabilmente criptato invece di essere semplicemente azzerato? Ok, usa /dev/random come origine dati invece di /dev/zero :

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

Su Linux, non continuiamo a reinventare tali ruote perché le funzionalità principali del sistema operativo non solo funzionano abbastanza bene, ma funzionano così bene da essere utilizzate in modo pervasivo. Uno schema tipico per l'avvio di una macchina Linux prevede un'immagine del disco virtuale, solo per un esempio, creata usando tecniche come quella mostrata sopra.⁷

Penso sia giusto sottolineare che se Unix avesse integrato TCP/IP I/O nel filesystem fin dall'inizio, non avremmo il netcat vs socat vs Ncat rispetto a nc pasticcio, la cui causa era la stessa debolezza di progettazione che ha portato alla proliferazione dello strumento di imaging del disco e pulizia su Windows:mancanza di un sistema operativo accettabile.

Risposta lunga, parte 2:Pipe come file virtuali

Nonostante le sue radici in DOS, Windows non ha mai avuto una ricca tradizione da riga di comando.

Questo non vuol dire che Windows non abbia una riga di comando o che mancano molti programmi da riga di comando. Windows ha anche una shell di comandi molto potente in questi giorni, chiamata in modo appropriato PowerShell.

Tuttavia, ci sono effetti a catena di questa mancanza di una tradizione della riga di comando. Ottieni strumenti come DISKPART che è quasi sconosciuto nel mondo Windows, perché la maggior parte delle persone esegue il partizionamento del disco e simili tramite lo snap-in Computer Management MMC. Quindi, quando hai bisogno di script per la creazione di partizioni, trovi che DISKPART non è stato creato per essere guidato da un altro programma. Sì, puoi scrivere una serie di comandi in un file di script ed eseguirlo tramite DISKPART /S scriptfile , ma è tutto o niente. Quello che davvero in una situazione del genere è qualcosa di più simile a GNU parted , che accetterà comandi singoli come parted /dev/sdb mklabel gpt . Ciò consente al tuo script di gestire gli errori passo dopo passo.

Cosa c'entra tutto questo con "tutto è un file"? Facile:le pipe trasformano l'I/O del programma da riga di comando in "file", di una sorta. Le pipe sono flussi unidirezionali, non ad accesso casuale come un normale file su disco, ma in molti casi la differenza non ha conseguenze. L'importante è che tu possa allegare due programmi sviluppati in modo indipendente e farli comunicare tramite un semplice testo. In questo senso, due programmi qualsiasi progettati pensando a Unix Way possono comunicare.

Nei casi in cui hai davvero bisogno di un file, è facile trasformare l'output del programma in un file:

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

Ma perché scrivere l'output in un file temporaneo quando la filosofia "tutto è un file" ti offre un modo migliore? Se tutto ciò che vuoi fare è leggere l'output di quel comando in un vi buffer dell'editor, vi può farlo per te direttamente. Dal vi modalità "normale", diciamo:

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

Ciò inserisce l'output di quel programma nel buffer dell'editor attivo nella posizione corrente del cursore. Sotto il cofano, vi sta usando le pipe per connettere l'output del programma a un po' di codice che usa le stesse chiamate del sistema operativo che userebbe invece per leggere da un file. Non sarei sorpreso se i due casi di :r — cioè con e senza il ! — entrambi utilizzavano lo stesso ciclo di lettura dei dati generici in tutte le implementazioni comuni di vi . Non riesco a pensare a una buona ragione per non farlo.

Questa non è una funzionalità recente di vi , o; torna indietro all'antico ed(1) editor di testo.⁸

Questa potente idea compare più e più volte in Unix.

Per un secondo esempio, ricorda il mio mutt comando e-mail sopra. L'unico motivo per cui dovevo scriverlo come due comandi separati è che volevo che il file temporaneo fosse chiamato *.gz , in modo che l'allegato e-mail venga nominato correttamente. Se non mi interessava il nome del file, avrei potuto utilizzare la sostituzione del processo per evitare di creare il file temporaneo:

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

Ciò evita il temporaneo trasformando l'output di gzip -c in un FIFO (che è simile a un file) o in un /dev/fd oggetto (che è simile a un file). (Bash sceglie il metodo in base alle capacità del sistema, poiché /dev/fd non è disponibile ovunque.)

Per un terzo modo in cui questa potente idea appare in Unix, considera gdb su sistemi Linux. Questo è il debugger utilizzato per qualsiasi software scritto in C e C++. I programmatori che arrivano su Unix da altri sistemi guardano gdb e quasi invariabilmente si lamentano, "Che schifo, è così primitivo!" Quindi vanno alla ricerca di un debugger della GUI, ne trovano uno tra i tanti esistenti e continuano felicemente il loro lavoro... spesso senza mai rendersi conto che la GUI esegue solo gdb sotto, fornendo un bel guscio sopra di esso. Non ci sono debugger di basso livello in competizione sulla maggior parte dei sistemi Unix perché non è necessario che i programmi competano a quel livello. Tutto ciò di cui abbiamo bisogno è un buon strumento di basso livello su cui tutti possiamo basare i nostri strumenti di alto livello, se quello strumento di basso livello comunica facilmente tramite i tubi.

Ciò significa che ora abbiamo un'interfaccia debugger documentata che consentirebbe la sostituzione drop-in di gdb , ma sfortunatamente il principale concorrente di gdb non ha preso il percorso a basso attrito.

Tuttavia, è almeno possibile che qualche futuro gdb la sostituzione cadrebbe in modo trasparente semplicemente clonando la sua interfaccia a riga di comando. Per ottenere la stessa cosa su una scatola di Windows, i creatori dello strumento sostituibile avrebbero dovuto definire una sorta di plug-in formale o API di automazione. Ciò significa che non succede tranne che per i programmi più popolari, perché è molto lavoro creare sia una normale interfaccia utente a riga di comando che un'API di programmazione completa.

Questa magia avviene attraverso la grazia di un IPC pervasivo basato su testo.

Sebbene il kernel di Windows abbia pipe anonime in stile Unix, è raro vedere i normali programmi utente utilizzarli per IPC al di fuori di una shell dei comandi, perché Windows non ha questa tradizione di creare prima tutti i servizi principali in una versione da riga di comando, quindi costruire la GUI su superiore separatamente. Questo porta a non essere in grado di fare alcune cose senza la GUI, motivo per cui ci sono così tanti sistemi desktop remoti per Windows, rispetto a Linux:Windows è molto difficile da usare senza la GUI.

Al contrario, è comune amministrare in remoto box Unix, BSD, OS X e Linux in remoto tramite SSH. E come funziona, chiedi? SSH connette un socket di rete (che è simile a un file) a uno pseudo tty in /dev/pty* (che è simile a un file). Ora il tuo sistema remoto è connesso a quello locale tramite una connessione che corrisponde così perfettamente a Unix Way che puoi inviare dati tramite la connessione SSH, se necessario.

Ti stai facendo un'idea di quanto sia potente questo concetto ora?

Un flusso di testo con pipe è indistinguibile da un file dal punto di vista di un programma, tranne per il fatto che è unidirezionale. Un programma legge da una pipe nello stesso modo in cui legge da un file:tramite un descrittore di file. Gli FD sono assolutamente fondamentali per Unix; il fatto che file e pipe utilizzino la stessa astrazione per l'I/O su entrambi dovrebbe dirti qualcosa.⁹

Il mondo Windows, privo di questa tradizione di semplici comunicazioni di testo, si accontenta di interfacce OOP pesanti tramite COM o .NET. Se devi automatizzare un tale programma, devi anche scrivere un programma COM o .NET. Questo è un po' più difficile che impostare una pipe su un box Unix.

I programmi Windows privi di queste complicate API di programmazione possono comunicare solo attraverso interfacce povere come gli appunti o File/Salva seguiti da File/Apri.

Risposta lunga, parte 3:il registro e i file di configurazione

La differenza pratica tra il registro di Windows e la configurazione del sistema Unix Way illustra anche i vantaggi della filosofia "tutto è un file".

Sui sistemi di tipo Unix, posso guardare le informazioni sulla configurazione del sistema dalla riga di comando semplicemente esaminando i file. Posso cambiare il comportamento del sistema modificando quegli stessi file. Per la maggior parte, questi file di configurazione sono solo file di testo normale, il che significa che posso utilizzare qualsiasi strumento su Unix per manipolarli in modo da funzionare con file di testo normale.

Lo script del registro non è così facile su Windows.

Il metodo più semplice è apportare le modifiche tramite la GUI dell'Editor del Registro di sistema su una macchina, quindi applicare ciecamente tali modifiche ad altre macchine con regedit tramite *.reg File. Questo non è davvero "scripting", dal momento che non ti consente di fare nulla in modo condizionale:è tutto o niente.

Se le modifiche al registro richiedono una certa quantità di logica, l'opzione successiva più semplice è apprendere PowerShell, che sostanzialmente equivale ad apprendere la programmazione di sistema .NET. Sarebbe come se Unix avesse solo Perl e dovessi fare tutto ad hoc amministrazione del sistema attraverso di essa. Ora, io sono un fan di Perl, ma non tutti lo sono. Unix ti consente di utilizzare qualsiasi strumento ti piaccia, purché sia ​​in grado di manipolare file di testo normale.

Note a piè di pagina:

1. Il piano 9 ha corretto questo passo falso di progettazione, esponendo l'I/O di rete tramite il /net filesystem virtuale.

Bash ha una funzione chiamata /dev/tcp che consente l'I/O di rete tramite le normali funzioni del filesystem. Poiché è una funzionalità di Bash, piuttosto una funzionalità del kernel, non è visibile al di fuori di Bash o su sistemi che non utilizzano affatto Bash. Questo mostra, per controesempio, perché è una buona idea rendere visibili tutte le risorse di dati attraverso il filesystem.

1. Con "Windows moderno" intendo Windows NT e tutti i suoi diretti discendenti, che includono Windows 2000, tutte le versioni di Windows Server e tutte le versioni desktop di Windows da XP in poi. Uso il termine per escludere le versioni basate su DOS di Windows, essendo Windows 95 e i suoi diretti discendenti, Windows 98 e Windows ME, oltre ai loro predecessori a 16 bit.

Puoi vedere la distinzione per la mancanza di un sistema I/O unificato in questi ultimi sistemi operativi. Non puoi passare un socket TCP/IP a ReadFile() su Windows 95; puoi passare i socket solo alle API di Windows Sockets. Consulta l'articolo fondamentale di Andrew Schulman, Windows 95:cosa non è per approfondire questo argomento.

1. Non commettere errori, /dev/null è un vero dispositivo del kernel su sistemi di tipo Unix, non solo un nome di file con case speciali, come è superficialmente equivalente NUL in Windows.

Sebbene Windows tenti di impedirti di creare un NUL file, è possibile aggirare questa protezione con un semplice inganno, ingannando la logica di analisi del nome file di Windows. Se provi ad accedere a quel file con cmd.exe o Explorer, Windows rifiuterà di aprirlo, ma puoi scriverci tramite Cygwin, poiché apre i file utilizzando metodi simili al programma di esempio e puoi eliminarlo con un trucco simile.

Al contrario, Unix ti farà felicemente rm /dev/null , purché tu abbia accesso in scrittura a /dev e ti consente di ricreare un nuovo file al suo posto, il tutto senza trucchi, perché quel nodo di sviluppo è solo un altro file. Mentre quel nodo di sviluppo è mancante, il dispositivo nullo del kernel esiste ancora; è semplicemente inaccessibile finché non ricrei il nodo dev tramite mknod .

Puoi persino creare nodi di sviluppo di dispositivi null aggiuntivi altrove:non importa se lo chiami /home/grandma/Recycle Bin , purché sia ​​un nodo di sviluppo per il dispositivo nullo, funzionerà esattamente come /dev/null .

1. In realtà sono due API di "formattazione disco" di alto livello in Windows:SHFormatDrive() e Win32_Volume.Format() .

Ce ne sono due per un molto... beh... Windows sorta di ragione. Il primo chiede a Windows Explorer di visualizzare la sua normale finestra di dialogo "Formatta disco", il che significa che funziona su qualsiasi versione moderna di Windows, ma solo mentre un utente è connesso in modo interattivo. L'altro puoi chiamare in background senza l'input dell'utente, ma non è stato aggiunto a Windows fino a Windows Server 2003. Esatto, il comportamento del sistema operativo principale è stato nascosto dietro una GUI fino al 2003, in un mondo in cui Unix ha distribuito mkfs dal giorno 1.

La mia copia di Unix V5 del 1974 include /etc/mkfs , un eseguibile PDP-11 con collegamento statico di 4136 byte. (Unix non ha ottenuto il collegamento dinamico fino alla fine degli anni '80, quindi non è che ci sia una grande libreria da qualche altra parte che fa tutto il vero lavoro.) Il suo codice sorgente — incluso nell'immagine di sistema V5 come /usr/source/s2/mkfs.c — è un programma C a 457 linee completamente autonomo. Non ci sono nemmeno #include dichiarazioni!

Ciò significa che non puoi solo esaminare cosa mkfs lo fa ad alto livello, puoi sperimentarlo usando lo stesso set di strumenti con cui Unix è stato creato, proprio come sei Ken Thompson, quattro decenni fa. Provalo con Windows. Il più vicino possibile oggi è scaricare il codice sorgente DOS, rilasciato per la prima volta nel 2014 , che trovi equivale a solo una pila di fonti di assemblaggio. Si costruirà solo con strumenti obsoleti che probabilmente non avrai a portata di mano, e alla fine otterrai la tua copia personale di DOS 2.0, un sistema operativo molto meno potente di Unix V5 del 1974, nonostante sia stato rilasciato quasi un decennio dopo.

(Perché parlare di Unix V5? Perché è il primo sistema Unix completo ancora disponibile. Le versioni precedenti sono apparentemente perse nel tempo. C'era un progetto che metteva insieme un Unix dell'era V1/V2, ma sembra che manchi mkfs , nonostante l'esistenza della pagina del manuale V1 collegata sopra che dimostri che deve essere esistita da qualche parte, da qualche parte. O coloro che hanno messo insieme questo progetto non sono riusciti a trovare una copia esistente di mkfs per includere, o faccio schifo a trovare file senza find(1) , che inoltre non esiste in quel sistema. :) )

Ora potresti pensare:"Non posso semplicemente chiamare format.com ? Non è lo stesso su Windows di chiamare mkfs su Unix?" Ahimè, no, non è lo stesso, per una serie di motivi:

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

1. Quando parlo di dispositivi loop, parlo solo di Linux piuttosto che di Unix in generale perché i dispositivi loop non sono portabili tra sistemi di tipo Unix. Esistono meccanismi simili in OS X, BSD, ecc., ma la sintassi varia leggermente.

2. Ai tempi in cui le unità disco erano grandi come lavatrici e costavano più dell'auto di lusso del capo dipartimento, i grandi laboratori informatici condividevano una proporzione maggiore del loro spazio su disco collettivo rispetto ai moderni ambienti informatici. La capacità di innestare in modo trasparente un disco remoto nel filesystem locale ha reso questi sistemi distribuiti molto più facili da usare. È qui che otteniamo /usr/share , per esempio.

Contrasta Windows, dove un disco remoto è in genere mappato su una lettera di unità o è necessario accedervi tramite un percorso UNC, piuttosto che integrato in modo trasparente nel filesystem locale. Le lettere di guida ti offrono poche scelte per l'espressione simbolica; fa P: fare riferimento allo spazio "pubblico" su BigServer o alla directory "pacchetti" sul server mirror del software? Percorsi UNC significa che devi ricordare su quale server si trovano i tuoi file remoti, il che diventa difficile in una grande organizzazione con centinaia o migliaia di file server.

Windows non ha ricevuto collegamenti simbolici fino a Windows Vista, rilasciato nel 2007, che ha introdotto collegamenti simbolici NTFS. I collegamenti simbolici di Windows sono un po' più potenti dei collegamenti simbolici di Unix - una caratteristica di Unix dal 1977 - in quanto possono anche puntare a una condivisione di file remota, non solo a un percorso locale. Unix lo ha fatto in modo diverso, tramite NFS nel 1984, che si basa sulla funzionalità del punto di montaggio preesistente di Unix, che ha avuto sin dall'inizio.

Quindi, a seconda di come lo guardi, Windows ha seguito Unix di circa 2 o 3 decenni.

Anche in questo caso, i collegamenti simbolici non sono una parte normale dell'esperienza di un utente Windows, per un paio di motivi.

Innanzitutto, puoi crearli solo con il programma a riga di comando all'indietro MKLINK . Non puoi crearli da Esplora risorse, mentre gli equivalenti Unix a Esplora risorse di solito lo fanno ti consente di creare collegamenti simbolici.

In secondo luogo, la configurazione predefinita di Windows impedisce agli utenti normali di creare collegamenti simbolici, richiedendo di eseguire la shell dei comandi come amministratore o di concedere all'utente il permesso di crearli tramite un percorso oscuro in uno strumento che l'utente medio non ha mai visto, tanto meno sa come usare. (E a differenza della maggior parte dei problemi relativi ai privilegi di amministratore in Windows, l'UAC non è di alcun aiuto in questo caso.)

1. Le scatole Linux non utilizzano sempre un'immagine del disco virtuale nella sequenza di avvio. Ci sono molti modi diversi per farlo.

2. man ed

3. A proposito, anche i descrittori di socket di rete sono FD sottostanti.