"Tutto è un file" è un po 'glib. "Tutto appare da qualche parte nel filesystem " è più vicino al segno, e anche allora, è più un ideale che una legge di progettazione del sistema.
Ad esempio, i socket di dominio Unix non sono file, ma vengono visualizzati nel file system. È possibile ls -lun socket di dominio per visualizzare i suoi attributi, i catdati a / da uno, modificare il suo controllo di accesso tramite chmod, ecc.
Tuttavia, anche se i normali socket di rete TCP / IP vengono creati e manipolati con le stesse chiamate di sistema dei socket BSD dei socket di dominio Unix, i socket TCP / IP non vengono visualizzati nel filesystem, ¹ anche se non vi sono motivi particolarmente validi per cui ciò dovrebbe essere vero.
Un altro esempio di oggetti non file che appaiono nel filesystem è il /procfilesystem di Linux . Questa funzione espone una grande quantità di dettagli sull'operazione di runtime del kernel nello spazio utente , principalmente come file di testo normale virtuale. Molte /procvoci sono di sola lettura, ma molte /procsono anche scrivibili, quindi puoi cambiare il modo in cui il sistema funziona usando qualsiasi programma in grado di modificare un file. Ahimè, anche qui abbiamo una non-idealità: gli Unix di tipo BSD generalmente funzionano senza/proc , e gli Unix di System V espongono molto meno tramite /procLinux.
Non posso contrastarlo con MS Windows
Innanzitutto, gran parte del sentimento che puoi trovare online e nei libri su Unix è tutto sull'I / O dei file e che Windows è "rotto" a questo proposito è obsoleto. Windows NT ha risolto molto di questo.
Le versioni moderne di Windows hanno un sistema I / O unificato, proprio come Unix, quindi puoi leggere i dati di rete da un socket TCP / IP tramite ReadFile()l'API specifica di Windows Socket WSARecv(), se lo desideri. Questo è esattamente parallelo a Unix Way , dove è possibile leggere da un socket di rete con la read(2)chiamata di sistema Unix generica o la chiamata specifica per recv(2)socket.
Tuttavia, Windows non riesce ancora a portare questo concetto allo stesso livello di Unix, anche qui nel 2018. Esistono molte aree dell'architettura Windows a cui non è possibile accedere tramite il file system o che non possono essere visualizzate come file. Qualche esempio:
Driver.
Il sottosistema di driver di Windows è facilmente ricco e potente come quello di Unix, ma per scrivere programmi per manipolare i driver, in genere è necessario utilizzare il Windows Driver Kit , che significa scrivere codice C o .NET.
Su sistemi operativi di tipo Unix, puoi fare molto ai driver dalla riga di comando. Quasi sicuramente lo hai già fatto, anche solo reindirizzando l'output indesiderato a /dev/null.³
Comunicazione tra programmi.
I programmi Windows non comunicano facilmente tra loro.
I programmi della riga di comando Unix comunicano facilmente tramite flussi di testo e pipe. I programmi GUI sono spesso basati su programmi a riga di comando o esportano un'interfaccia di comando di testo, in modo che gli stessi semplici meccanismi di comunicazione basati su testo funzionino anche con i programmi GUI.
Il registro.
Unix non ha un equivalente diretto del registro di Windows. Le stesse informazioni sono sparse nel filesystem, la maggior parte in /etc, /proce /sys.
Se non vedi che i driver, le pipe e la risposta di Unix al registro di Windows hanno qualcosa a che fare con "tutto è un file", continua a leggere.
In che modo la filosofia "Tutto è un file" fa la differenza qui?
Lo spiegherò espandendo in dettaglio i miei tre punti sopra.
Risposta lunga, parte 1: Drives vs Device Files
Diciamo che il tuo lettore di schede CF appare come E:sotto Windows e /dev/sdcsotto Linux. Che differenza pratica fa?
Non è solo una piccola differenza di sintassi.
Su Linux, posso dire dd if=/dev/zero of=/dev/sdcdi sovrascrivere il contenuto /dev/sdccon zero.
Pensa a cosa significa per un secondo. 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 scrivere ciò che legge su un dispositivo fisico reale ( /dev/sdc) tramite il filesystem Unix unificato. ddnon sa che sta leggendo e scrivendo su dispositivi speciali. Funzionerà anche su file regolari o su un mix di dispositivi e file, come vedremo di seguito.
Non esiste un modo semplice per azzerare l' E:unità su Windows, perché Windows fa una distinzione tra file e unità, quindi non è possibile utilizzare gli stessi comandi per manipolarli. Il più vicino che puoi ottenere è fare un formato del disco senza l'opzione Quick Format, che azzera la maggior parte dei contenuti dell'unità, ma poi scrive un nuovo filesystem su di esso. Cosa succede se non desidero un nuovo filesystem? E se volessi davvero riempire il disco con nient'altro che zero?
Siamo generosi e diciamo che vogliamo davvero un nuovo nuovo filesystem 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à del "disco del formato" del sistema operativo. Basta eseguire il programma spaziale utente appropriato per il tipo di filesystem che si desidera creare: mkfs.ext4, mkfs.xfs, o quello che hai. Questi programmi scriveranno un filesystem su qualunque file o /devnodo che passi.
Poiché i mkfsprogrammi di tipo sui sistemi Unixy funzionano sui file senza fare distinzioni artificiali tra dispositivi e file normali, ciò significa che posso creare un filesystem ext4 all'interno di un file normale sul mio box Linux:
$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs
Ciò crea letteralmente un'immagine del 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 del disco ext4 con un file chiamato my-passwd-entryche contiene la /etc/passwdvoce del mio utente .
Se voglio, posso far saltare quell'immagine sulla mia scheda CF:
$ sudo dd if=myfs of=/dev/sdc1
Oppure, posso impacchettare quell'immagine del disco, inviarla via e-mail e lasciarti scrivere su un supporto di tua scelta, come 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" you@example.com
Tutto ciò è possibile su Linux⁵ perché non esiste una distinzione artificiale tra file, filesystem e dispositivi. Molte cose sui sistemi Unix sono file o sono accessibili tramite il file system in modo che appaiano come file o in qualche modo sembrano sufficientemente file da poter essere trattati come tali.
Il concetto di Windows del filesystem è un miscuglio; distingue tra directory, unità e risorse di rete. Esistono tre diverse sintassi, tutte unite in Windows: il sistema di ..\FOO\BARpercorsi simile a Unix , lettere di unità simili C:e percorsi UNC come \\SERVER\PATH\FILE.TXT. Questo perché si tratta di un accrescimento di idee di Unix, CP / M , MS-DOS e LAN Manager , piuttosto che di un singolo progetto coerente. È per questo che ci sono così tanti personaggi 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 v'è alcuna differenza funzionale tra /etc/passwd, /media/CF_CARD/etc/passwde /mnt/server/etc/passwd. I file locali, i supporti esterni e le condivisioni di rete vengono tutti trattati allo stesso modo. ⁶
Windows può raggiungere scopi 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à del sistema operativo principale ha creato un mercato artificiale per i programmi per colmare il divario, il che significa che hai un sacco di persone in competizione per creare il miglior programma di tipo DVD virtuale. Non abbiamo bisogno di tali programmi su sistemi * ix, perché possiamo semplicemente montare un'immagine disco ISO usando un dispositivo loop .
Lo stesso vale per altri strumenti come i programmi di pulizia del disco , di cui non abbiamo nemmeno bisogno sui sistemi Unix. Vuoi che i contenuti della tua scheda CF siano irrimediabilmente criptati anziché azzerati? Bene, usa /dev/randomcome 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à del sistema operativo principale non solo funzionano abbastanza bene, funzionano così bene da essere utilizzate pervasivamente. Uno schema tipico per l'avvio di un box Linux prevede un'immagine del disco virtuale, per un solo esempio, creata usando tecniche come mostrato sopra. ⁷
Sento che sia giusto sottolineare che se Unix avesse integrato I / O TCP / IP nel filesystem dall'inizio, non avremmo avuto il disordinenetcat vs socatvs Ncatvs , la cui causa era la stessa debolezza progettuale che portava al proliferazione degli strumenti di imaging del disco e pulizia su Windows: mancanza di una struttura del sistema operativo accettabile.nc
Risposta lunga, parte 2: Tubi come file virtuali
Nonostante le sue radici in DOS, Windows non ha mai avuto una ricca tradizione da riga di comando.
Questo non significa che Windows non abbia una riga di comando o che manchi molti programmi da riga di comando. Oggigiorno Windows ha anche una shell di comandi molto potente, chiamata PowerShell in modo appropriato .
Tuttavia, ci sono effetti a catena di questa mancanza di una tradizione da riga di comando. Ottieni strumenti come i DISKPARTquali è quasi sconosciuto nel mondo di Windows, perché la maggior parte delle persone esegue il partizionamento del disco e simili attraverso lo snap-in MMC Gestione computer. Quindi, quando è necessario creare script per la creazione di partizioni, si scopre che DISKPARTnon è 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 vuoi davvero in una situazione del genere è qualcosa di più simile a GNUparted , che accetta comandi singoli come parted /dev/sdb mklabel gpt. Ciò consente allo script di eseguire la gestione degli errori su una base dettagliata.
Cosa c'entra tutto questo con "tutto è un file"? Semplice: le pipe trasformano l'I / O del programma da riga di comando in "file", di un tipo. Le pipe sono flussi unidirezionali , non un accesso casuale come un normale file su disco, ma in molti casi la differenza non ha alcuna conseguenza. L'importante è che tu possa allegare due programmi sviluppati in modo indipendente e farli comunicare tramite un semplice testo. In tal senso, ogni due programmi progettati pensando a Unix Way può 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 dà un modo migliore? Se tutto ciò che vuoi fare è leggere l'output di quel comando in un vibuffer dell'editor, vipuoi farlo direttamente per te. Dalla vimodalità "normale", dire:
: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, vista usando le pipe per connettere l'output del programma a un po 'di codice che utilizza 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 !- utilizzassero entrambi lo stesso ciclo di lettura di dati generici in tutte le implementazioni comuni di vi. Non riesco a pensare a una buona ragione per non farlo.
Anche questa non è una caratteristica recente di vi; risale all'antico ed(1)editor di testi
Questa potente idea si presenta più volte in Unix.
Per un secondo esempio di ciò, ricorda il mio muttcomando e-mail sopra. L'unica ragione per cui ho dovuto scrivere che come due comandi separati è che volevo che il file temporaneo fosse nominato *.gz, in modo che l'allegato e-mail fosse nominato correttamente. Se non mi importasse del nome del file, avrei potuto usare 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" you@example.com
Ciò evita il temporaneo trasformando l'output di gzip -cin un FIFO (che è simile a un file) o in un /dev/fdoggetto (che è simile a un file). (Bash sceglie il metodo in base alle capacità del sistema, poiché /dev/fdnon è disponibile ovunque.)
Per ancora un terzo modo in cui questa potente idea appare in Unix, considera gdbi sistemi Linux. Questo è il debugger utilizzato per qualsiasi software scritto in C e C ++. I programmatori che arrivano su Unix da altri sistemi guardano gdbe quasi invariabilmente si lamentano al riguardo, "Accidenti, è così primitivo!" Quindi vanno alla ricerca di un debugger della GUI, trovano uno dei tanti esistenti e continuano felicemente il loro lavoro ... spesso non si rendono mai conto che la GUI semplicemente scorre gdbsotto, fornendo una bella shell sopra di esso. Non ci sono debugger di basso livello concorrenti 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 tale strumento di basso livello comunica facilmente tramite tubi.
Ciò significa che ora abbiamo un'interfaccia di debugger documentata che consentirebbe la sostituzione drop-in gdb, ma sfortunatamente, il principale concorrente gdb non ha intrapreso il percorso a basso attrito .
Tuttavia, è almeno possibile che alcune future gdbsostituzioni entrino in modo trasparente semplicemente clonando la sua interfaccia da riga di comando. Per eseguire la stessa operazione su una finestra 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 difficile costruire sia una normale interfaccia utente da riga di comando sia un'API di programmazione completa.
Questa magia avviene attraverso la grazia di un diffuso IPC basato su testo .
Sebbene il kernel di Windows abbia pipe anonime in stile Unix , è raro vedere normali programmi utente usarli per IPC al di fuori di una shell di comando, 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 sopra separatamente. Ciò comporta l'impossibilità di fare alcune cose senza la GUI, motivo per cui esistono così tanti sistemi desktop remoti per Windows, rispetto a Linux: Windows è molto difficile da usare senza la GUI.
Al contrario, è comune amministrare in remoto caselle Unix, BSD, OS X e Linux in remoto tramite SSH. E come funziona, chiedi? SSH collega una presa di rete (che è simile a file) ad una pseudo tty a /dev/pty*(che è simile a file). Ora il tuo sistema remoto è collegato a quello locale tramite una connessione che si adatta in modo così uniforme al modo Unix che puoi reindirizzare i dati attraverso la connessione SSH , se necessario.
Hai un'idea di quanto sia potente questo concetto ora?
Un flusso di testo convogliato è indistinguibile da un file dalla prospettiva di un programma, tranne per il fatto che è unidirezionale. Un programma legge da una pipe nello stesso modo in cui legge da un file: attraverso 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 di Windows, privo di questa tradizione di semplici comunicazioni testuali, si accontenta di interfacce OOP pesanti via COM o .NET . Se è necessario automatizzare tale programma, è necessario anche scrivere un programma COM o .NET. Questo è un po 'più difficile che installare una pipe su una scatola Unix.
I programmi Windows privi di queste complicate API di programmazione possono comunicare solo attraverso interfacce impoverite come gli Appunti o File / Salva seguito da File / Apri.
Risposta lunga, parte 3: il registro vs i file di configurazione
La differenza pratica tra il registro di Windows e la modalità di configurazione del sistema Unix illustra anche i vantaggi della filosofia "tutto è un file".
Sui sistemi di tipo Unix, posso guardare le informazioni di 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 semplice, il che significa che posso usare qualsiasi strumento su Unix per manipolarli che possono funzionare con file di testo semplice.
Lo scripting del registro non è così semplice su Windows.
Il metodo più semplice è quello di rendere le modifiche attraverso l'Editor del Registro di GUI su una macchina, quindi applicare ciecamente le modifiche ad altre macchine con regeditvia *.regfile . Questo non è in realtà "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 all'apprendimento della programmazione del sistema .NET. Sarebbe come se Unix avesse solo Perl e tu dovessi fare tutta l' amministrazione del sistema ad hoc attraverso di essa. Ora 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 semplice.
Note:
Plan 9 ha corretto questo errore di progettazione, esponendo l'I / O di rete tramite il /netfilesystem virtuale .
Bash ha una funzione chiamata/dev/tcp che consente l'I / O di rete tramite le normali funzioni del filesystem. Dal momento che è una funzionalità di Bash, piuttosto una funzione del kernel, non è visibile al di fuori di Bash o su sistemi che non usano affatto Bash . Ciò dimostra, per controesempio, perché è una buona idea rendere visibili tutte le risorse di dati attraverso il filesystem.
Per "Windows moderno" intendo Windows NT e tutti i suoi discendenti diretti, tra cui 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 di Windows basate su DOS, essendo Windows 95 e i suoi discendenti diretti, Windows 98 e Windows ME, oltre ai loro predecessori a 16 bit.
È possibile vedere la distinzione dalla mancanza di un sistema I / O unificato in questi ultimi sistemi operativi. Non è possibile passare un socket TCP / IP ReadFile()su Windows 95; puoi solo passare i socket alle API di Windows Socket. Vedi l'articolo fondamentale di Andrew Schulman, Windows 95: What Is Not per un approfondimento su questo argomento.
Non commettere errori, /dev/nullè un vero dispositivo kernel nei sistemi di tipo Unix, non solo un nome di file con casing speciale, come è superficialmente equivalente NULin Windows.
Sebbene Windows cerchi di impedirti di creare un NULfile, è possibile aggirare questa protezione con un semplice trucco , ingannando la logica di analisi del nome file di Windows. Se provi ad accedere a quel file con cmd.exeo Explorer, Windows rifiuterà di aprirlo, ma puoi scriverlo tramite Cygwin, poiché apre i file utilizzando metodi simili al programma di esempio e puoi eliminarlo tramite un trucco simile .
Al contrario, Unix ti consentirà felicemente rm /dev/null, a condizione che tu abbia accesso in scrittura /deve ti permetta di ricreare un nuovo file al suo posto, il tutto senza difficoltà, perché quel nodo dev è solo un altro file. Mentre quel nodo dev manca, il dispositivo null del kernel esiste ancora; è inaccessibile fino a quando non si ricrea il nodo dev tramite mknod.
Puoi persino creare altri nodi dev dispositivo null altrove: non importa se lo chiami /home/grandma/Recycle Bin, purché sia un nodo dev per il dispositivo null, funzionerà esattamente come /dev/null.
Esistono in realtà due API di "formattazione del disco" di alto livello in Windows: SHFormatDrive()e Win32_Volume.Format().
Ce ne sono due per una ragione ... beh ... per Windows . Il primo chiede a Esplora risorse di visualizzare la 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 è possibile chiamare in background senza 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 è stato spedito mkfs dal primo giorno .
La mia copia di Unix V5 del 1974 include /etc/mkfsun eseguibile PDP-11 a 4136 byte con collegamento statico . (Unix non ha avuto un 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 del sistema V5 come /usr/source/s2/mkfs.c- è un 457 completamente autonomo programma linea C. Non ci sono nemmeno #includedichiarazioni!
Ciò significa che non solo puoi esaminare ciò che mkfsfa ad alto livello, ma puoi sperimentarlo usando lo stesso set di strumenti con cui Unix è stato creato, proprio come sei Ken Thompson , quattro decenni fa. Prova con Windows. Il più vicino che puoi venire oggi è scaricare il codice sorgente DOS , rilasciato per la prima volta nel 2014 , che trovi ammonta a un mucchio di fonti di assemblaggio . Costruirà solo con strumenti obsoleti che probabilmente non avrai a portata di mano, e alla fine otterrai la tua copia 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 mancare mkfs, nonostante l'esistenza della pagina di manuale V1 collegata sopra dimostrando che deve essere esistito da qualche parte, in qualche modo. O quelli che mettono insieme questo progetto non sono riusciti a trovare una copia esistente di mkfsincludere, o faccio schifo nel trovare file senza find(1), che non esiste nemmeno in quel sistema . :))
Ora, potresti pensare: "Non posso semplicemente chiamare format.com? Non è lo stesso su Windows come chiamare mkfsUnix?" Ahimè, no, non è lo stesso, per una serie di motivi:
Innanzitutto, format.comnon è stato progettato per essere copiato. Ti chiede di "premere INVIO quando pronto", il che significa che devi inviare un tasto Invio al suo input, o si bloccherà.
Quindi, se vuoi qualcosa di più di un codice di stato di successo / fallimento, devi aprire il suo output standard per la lettura, che è molto più complicato su Windows di quanto non lo sia . (Su Unix, tutto in quell'articolo collegato può essere realizzato con una semplice popen(3)chiamata.)
Avendo superato tutta questa complicazione, l'output di format.comè più difficile da analizzare per i programmi per computer rispetto all'output di mkfs, essendo destinato principalmente al consumo umano.
Se si traccia quello che format.comfa, ci si accorge che fa un sacco di chiamate complicate a DeviceIoControl(), ufat.dll, e così via. Non sta semplicemente aprendo un file dispositivo e scrivendo un nuovo filesystem su quel dispositivo. Questo è il tipo di design che ottieni da un'azienda che impiega 126000 persone e deve continuare a impiegarle.
Quando parlo di dispositivi loop, parlo solo di Linux piuttosto che di Unix in generale perché i dispositivi loop non sono portatili tra sistemi di tipo Unix. Esistono meccanismi simili in OS X, BSD, ecc., Ma la sintassi varia leggermente .
Ai tempi in cui le unità disco avevano le dimensioni di lavatrici e costavano di più rispetto all'auto di lusso del capo dipartimento, i grandi laboratori informatici condividevano una parte 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. Questo è dove arriviamo /usr/share, per esempio.
Contrasta Windows, in cui un disco remoto è in genere mappato a una lettera di unità o deve essere accessibile tramite un percorso UNC, anziché integrato in modo trasparente nel file system locale. Le lettere di unità offrono poche opzioni per l'espressione simbolica; fa P:riferimento allo spazio "pubblico" su BigServer o alla directory "pacchetti" sul server mirror software? I percorsi UNC significano 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 ottenuto collegamenti simbolici fino a quando Windows Vista, rilasciato nel 2007, ha introdotto i 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 indicare una condivisione di file remota, non solo un percorso locale. Unix ha fatto diversamente, tramite NFS nel 1984 , che si basa sulla preesistente funzionalità mount point di Unix , che ha avuto sin dall'inizio.
Quindi, a seconda di come lo vedi, Windows ha seguito Unix per circa 2 o 3 decenni.
Anche in questo caso, i collegamenti simbolici non fanno parte dell'esperienza di un utente di Windows, per un paio di motivi.
Innanzitutto, puoi crearli solo con il programma da riga di comando all'indietroMKLINK . Non è possibile creare loro di Esplora risorse di Windows, mentre gli equivalenti UNIX a Windows Explorer in genere non consentono di creare link 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 autorizzare l'utente a crearli tramite un percorso oscuro in uno strumento che l'utente medio non ha mai visto, tanto meno lo sa come usare. (E a differenza della maggior parte dei problemi relativi ai privilegi di amministratore in Windows, UAC non è di alcun aiuto in questo caso.)
I box Linux non usano sempre un'immagine del disco virtuale nella sequenza di avvio. Esistono diversi modi per farlo .
man ed
A proposito, anche i descrittori dei socket di rete sono FD sottostanti.