Skip to content

Une explication de profane pour "Tout est un fichier" - ce qui diffère de Windows ?

Restez à l'écoute car dans cet article, vous trouverez la réponse que vous cherchez.

Solution :

"Tout est un fichier" est un peu facile. "Tout apparaît quelque part dans le système de fichiers" est plus proche de la marque, et même alors, c'est plus un idéal qu'une loi de la conception du système.

Par exemple, les sockets de domaine Unix ne sont pas des fichiers, mais ils apparaissent dans le système de fichiers. Vous pouvez ls -l un socket de domaine pour afficher ses attributs, modifier son contrôle d'accès par l'intermédiaire de chmodet sur certains systèmes de type Unix (par exemple macOS, mais pas Linux), vous pouvez même cat .catdonnées vers/depuis un.

Mais, même si les sockets ordinaires du réseau TCP/IP sont créées et manipulées avec les mêmes appels système BSD sockets que les sockets de domaine Unix, les sockets TCP/IP font... pas apparaître dans le système de fichiers,¹ même s'il n'y a pas de raison particulièrement bonne pour que cela soit vrai.

Un autre exemple d'objets non-fichiers apparaissant dans le système de fichiers est celui de Linux. /proc de Linux. Cette fonctionnalité expose une grande quantité de détails sur l'opération d'exécution du noyau à l'espace utilisateur, principalement sous la forme de fichiers de texte brut virtuels. Beaucoup de /proc sont en lecture seule, mais beaucoup de fichiers /proc est aussi accessible en écriture, donc vous pouvez changer la façon dont le système fonctionne en utilisant n'importe quel programme qui peut modifier un fichier. Hélas, ici encore nous avons une non-idéalité : Les Unix de type BSD fonctionnent généralement sans /procet les Unix de type System V en exposent beaucoup moins via la fonction /proc que Linux.

Je ne peux pas opposer cela à MS Windows

Tout d'abord, une grande partie du sentiment que vous pouvez trouver en ligne et dans les livres sur Unix étant tout sur les E/S de fichiers et Windows étant "cassé" à cet égard est obsolète. Windows NT a corrigé une grande partie de cela.

Les versions modernes de Windows ont un système d'E/S unifié, tout comme Unix, de sorte que vous pouvez lire des données réseau à partir d'une socket TCP/IP via... ReadFile() plutôt que l'API spécifique de Windows Sockets WSARecv()si vous le souhaitez. Cela correspond exactement à la manière Unix, où vous pouvez lire à partir d'une socket réseau avec soit l'API générique read(2) générique d'Unix, soit l'appel système spécifique aux sockets recv(2) spécifique aux sockets.²

Néanmoins, Windows ne parvient toujours pas à porter ce concept au même niveau qu'Unix, même ici en 2021. Il existe de nombreuses zones de l'architecture Windows auxquelles on ne peut pas accéder par le biais du système de fichiers, ou qui ne peuvent pas être considérées comme des fichiers. Quelques exemples :

  1. Pilotes.

Le sous-système de pilotes de Windows est facilement aussi riche et puissant que celui d'Unix, mais pour écrire des programmes pour manipuler les pilotes, vous devez généralement utiliser le kit de pilotes Windows, ce qui signifie écrire du code C ou .NET.

Sur les OS de type Unix, vous pouvez faire beaucoup de choses aux pilotes à partir de la ligne de commande. Vous l'avez presque certainement déjà fait, ne serait-ce qu'en redirigeant les sorties indésirables vers... /dev/null

  1. Communication inter-programmes.

Les programmes Windows ne communiquent pas facilement entre eux.

Les programmes de ligne de commande Unix communiquent facilement via des flux de texte et des tuyaux. Les programmes GUI sont souvent soit construits au-dessus des programmes de ligne de commande, soit exportent une interface de commande textuelle, de sorte que les mêmes mécanismes de communication textuelle simples fonctionnent également avec les programmes GUI.

  1. Le registre.

Unix n'a pas d'équivalent direct du registre de Windows. Les mêmes informations sont disséminées dans le système de fichiers, la plupart d'entre elles dans les fichiers de la base de données. /etc, /proc et /sys.

Si vous ne voyez pas que les pilotes, les pipes, et la réponse d'Unix au registre de Windows ont quelque chose à voir avec "tout est un fichier", lisez la suite.

En quoi la philosophie "Tout est un fichier" fait-elle une différence ici ?

Je vais expliquer cela en développant mes trois points ci-dessus, en détail.

Réponse longue, partie 1 : Lecteurs vs fichiers de périphériques

Disons que votre lecteur de carte CF apparaît comme suit . E: sous Windows et /dev/sdc sous Linux. Quelle différence pratique cela fait-il ?

Ce n'est pas seulement une différence mineure de syntaxe.

Sous Linux, je peux dire dd if=/dev/zero of=/dev/sdc pour écraser le contenu de /dev/sdc avec des zéros.

Pensez à ce que cela signifie pendant une seconde. Ici, j'ai un programme normal en espace utilisateur (dd(1)) auquel j'ai demandé de lire des données à partir d'un périphérique virtuel (/dev/zero) et d'écrire ce qu'il a lu sur un périphérique physique réel (/dev/sdc) via le système de fichiers unifié d'Unix. dd ne sait pas qu'il lit et écrit sur des périphériques spéciaux. Il fonctionnera sur des fichiers ordinaires tout aussi bien, ou sur un mélange de périphériques et de fichiers, comme nous le verrons ci-dessous.

Il n'y a pas de moyen facile de mettre à zéro le E: sous Windows, parce que Windows fait une distinction entre les fichiers et les lecteurs, donc vous ne pouvez pas utiliser les mêmes commandes pour les manipuler. Le plus proche que vous puissiez obtenir est de faire un formatage de disque sans l'option de formatage rapide, qui met à zéro... la plupart des du contenu du disque, mais écrit ensuite un nouveau système de fichiers par-dessus. Et si je n'ai pas veux pas un nouveau système de fichiers ? Et si je veux vraiment que le disque ne soit rempli que de zéros ?

Soyons généreux et disons que nous voulons vraiment un nouveau système de fichiers sur E:. Pour le faire dans un programme sous Windows, je dois appeler une API de formatage spéciale.⁴ Sous Linux, vous n'avez pas besoin d'écrire un programme pour accéder à la fonctionnalité de " formatage de disque " du système d'exploitation. Vous exécutez simplement le programme d'espace utilisateur approprié pour le type de système de fichiers que vous voulez créer : mkfs.ext4, mkfs.xfsou ce que vous voulez. Ces programmes écriront un système de fichiers sur n'importe quel fichier ou disque. /dev que vous passez.

Parce que mkfs sur les systèmes Unixy fonctionnent sur les fichiers sans faire de distinctions artificielles entre les périphériques et les fichiers normaux, cela signifie que je peux créer un système de fichiers ext4 à l'intérieur d'un fichier normal sur ma boîte Linux :

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

Cela crée littéralement une image disque de 1 MiB dans le répertoire courant, appelé myfs. Je peux ensuite la monter comme s'il s'agissait de n'importe quel autre système de fichiers externe :

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

Maintenant, j'ai une image disque ext4 avec un fichier appelé my-passwd-entry qui contient le nom de mon utilisateur /etc/passwd de mon utilisateur.

Si je veux, je peux faire sauter cette image sur ma carte CF :

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

Ou, je peux emballer cette image disque, vous l'envoyer par courrier, et vous laisser l'écrire sur un support de... votre choix, comme une clé 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]

Tout ceci est possible sur Linux⁵ car il n'y a pas de distinction artificielle entre les fichiers, les systèmes de fichiers et les périphériques. Beaucoup de choses sur les systèmes Unix soit sont des fichiers, ou sont accédés par le système de fichiers de telle sorte qu'ils ressemblent à ou, d'une autre manière, ressemblent suffisamment à des fichiers pour pouvoir être traités comme tels.

Le concept de système de fichiers de Windows est un hodgepodg.e; il fait des distinctions entre les répertoires, les lecteurs et les ressources réseau. Il existe trois syntaxes différentes, toutes mélangées dans Windows : la syntaxe de type Unix. ..FOOBAR système de chemin, les lettres de lecteur comme C:et les chemins UNC comme \SERVERPATHFILE.TXT. C'est parce que c'est une accrétion d'idées provenant d'Unix, de CP/M, de MS-DOS et de LAN Manager, plutôt qu'une seule conception cohérente. C'est pourquoi il y a tant de caractères illégaux dans les noms de fichiers Windows.

Unix a un système de fichiers unifié, avec tout accessible par un seul schéma commun. Pour un programme fonctionnant sur une boîte Linux, il n'y a pas de différence fonctionnelle entre... /etc/passwd, /media/CF_CARD/etc/passwdet /mnt/server/etc/passwd. Les fichiers locaux, les médias externes et les partages réseau sont tous traités de la même manière.⁶

Windows peut atteindre des fins similaires à mon exemple d'image disque ci-dessus, mais vous devez utiliser des programmes spéciaux écrits par des programmeurs au talent peu commun. C'est pourquoi il y a tant de programmes de type "DVD virtuel" sous Windows. L'absence d'une fonctionnalité essentielle du système d'exploitation a créé un marché artificiel pour les programmes destinés à combler cette lacune, ce qui signifie qu'un grand nombre de personnes sont en concurrence pour créer le meilleur programme de type DVD virtuel. Nous n'avons pas besoin de tels programmes sur les systèmes *ix, car nous pouvons simplement monter une image disque ISO en utilisant un périphérique de boucle.

Il en va de même pour d'autres outils comme les programmes d'effacement de disque, dont nous n'avons pas non plus besoin sur les systèmes Unix. Vous voulez que le contenu de votre carte CF soit irrémédiablement brouillé au lieu d'être simplement mis à zéro ? Ok, utilisez /dev/random comme source de données au lieu de /dev/zero:

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

Sous Linux, nous ne réinventons pas sans cesse de telles roues parce que les fonctionnalités de base du système d'exploitation ne fonctionnent pas seulement assez bien, elles fonctionnent si bien qu'elles sont utilisées de manière omniprésente. Un schéma typique pour démarrer une boîte Linux implique une image de disque virtuel, pour un seul exemple, créé en utilisant des techniques comme je montre ci-dessus.⁷

Je pense qu'il est juste de souligner que si Unix avait intégré les E/S TCP/IP dans le système de fichiers dès le début, nous n'aurions pas le... netcat vs socat vs Ncat vs nc dont la cause était la même faiblesse de conception qui a conduit à la prolifération des outils d'imagerie et d'effacement de disque sur Windows : l'absence d'une facilité acceptable pour le système d'exploitation.

Réponse longue, partie 2 : les tuyaux en tant que fichiers virtuels.

Malgré ses racines dans DOS, Windows n'a jamais eu une riche tradition de ligne de commande.

Cela ne veut pas dire que Windows n'a pas... a une ligne de commande, ou qu'il manque de nombreux programmes de ligne de commande. Windows a même un shell de commande très puissant de nos jours, appelé de manière appropriée PowerShell.

Pourtant, il y a des effets d'entraînement de ce manque de tradition de ligne de commande. Vous obtenez des outils comme DISKPART qui est presque inconnu dans le monde Windows, parce que la plupart des gens font le partitionnement des disques et autres via le snap-in MMC de gestion des ordinateurs. Ensuite, lorsque vous avez besoin de scripter la création de partitions, vous constatez que DISKPART n'a pas vraiment été conçu pour être piloté par un autre programme. Oui, vous pouvez écrire une série de commandes dans un fichier script et le lancer via DISKPART /S scriptfilemais c'est tout ou rien. Ce que vous vraiment dans une telle situation est quelque chose qui ressemble plus à GNU partedqui acceptera des commandes simples comme parted /dev/sdb mklabel gpt. Cela permet à votre script de faire de la gestion d'erreur sur une base étape par étape.

Qu'est-ce que tout cela a à voir avec "tout est un fichier" ? C'est simple : les tubes transforment les entrées/sorties des programmes en ligne de commande en "fichiers", en quelque sorte. Les pipes sont des flux unidirectionnels, et non à accès aléatoire comme un fichier disque ordinaire, mais dans de nombreux cas, la différence n'a pas d'importance. L'important, c'est que vous pouvez joindre deux programmes développés indépendamment et les faire communiquer par un simple texte. En ce sens, n'importe quels deux programmes conçus avec la méthode Unix Way à l'esprit peuvent communiquer.

Dans les cas où vous avez vraiment besoin d'un fichier, il est facile de transformer la sortie du programme en fichier :

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

Mais pourquoi écrire la sortie dans un fichier temporaire quand la philosophie "tout est un fichier" vous donne un meilleur moyen ? Si tout ce que vous voulez faire est de lire la sortie de cette commande dans un fichier vi . vi tampon de l'éditeur, vi peut le faire directement pour vous. Depuis le vi mode "normal", dites :

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

Cela insère la sortie de ce programme dans le tampon actif de l'éditeur à la position actuelle du curseur. Sous le capot, viutilise des tuyaux pour connecter la sortie du programme à un bout de code qui utilise les mêmes appels OS qu'il utiliserait pour lire un fichier. Je ne serais pas surpris si les deux cas de :r - c'est à dire avec et sans le ! - utilisent tous deux la même boucle générique de lecture de données dans toutes les implémentations communes de vi. Je ne peux pas penser à une bonne raison de ne pas le faire.

Ce n'est pas une caractéristique récente de vinon plus ; cela remonte clairement à l'ancienne version de la norme ed(1) éditeur de texte.⁸

Cette idée puissante apparaît encore et encore dans Unix.

Pour un second exemple de ceci, rappelez-vous mon mutt commande email ci-dessus. La seule raison pour laquelle j'ai dû écrire cela comme deux commandes distinctes est que je voulais que le fichier temporaire soit nommé... *.gzafin que la pièce jointe du courriel soit correctement nommée. Si je ne me souciais pas du nom du fichier, j'aurais pu utiliser la substitution de processus pour éviter de créer le fichier temporaire :

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

Cela évite le temporaire en transformant la sortie de gzip -c en un FIFO (qui est semblable à un fichier) ou un /dev/fd (qui est semblable à un fichier). (Bash choisit la méthode en fonction des capacités du système, puisque l'objet /dev/fd n'est pas disponible partout).

Pour encore une troisième façon dont cette idée puissante apparaît dans Unix, considérez . gdb sur les systèmes Linux. C'est le débogueur utilisé pour tout logiciel écrit en C et C++. Les programmeurs qui viennent à Unix depuis d'autres systèmes regardent gdb et râlent presque invariablement à son sujet, "Beurk, c'est si primitif !". Puis ils se mettent à la recherche d'un débogueur d'interface graphique, en trouvent un parmi plusieurs qui existent, et continuent joyeusement leur travail... souvent sans se rendre compte que l'interface graphique exécute juste gdb en dessous, fournissant un joli shell par-dessus. Il n'y a pas de débogueurs de bas niveau concurrents sur la plupart des systèmes Unix parce qu'il n'y a pas besoin que les programmes soient en compétition à ce niveau. Tout ce dont nous avons besoin est un bon outil de bas niveau sur lequel nous pouvons tous baser nos outils de haut niveau, si cet outil de bas niveau communique facilement via des pipes.

Cela signifie que nous disposons maintenant d'une interface de débogueur documentée qui permettrait de remplacer sans difficulté les outils suivants gdbmais malheureusement, le principal concurrent de gdb n'a pas pris le chemin de faible friction.

Tout de même, c'est au moins possible que que certains futurs gdb remplacement s'installe de manière transparente en clonant simplement son interface de ligne de commande. Pour faire la même chose sur une machine Windows, les créateurs de l'outil remplaçable auraient dû définir une sorte de plugin formel ou d'API d'automatisation. Cela signifie que cela ne se produit pas, sauf pour les programmes très populaires, car c'est beaucoup de travail de construire à la fois une interface utilisateur en ligne de commande normale et une API de programmation complète.

Cette magie se produit par la grâce d'un IPC textuel omniprésent.

Bien que le noyau de Windows ait des tuyaux anonymes de style Unix, il est rare de voir des programmes utilisateurs normaux les utiliser pour l'IPC en dehors d'un shell de commande, parce que Windows manque cette tradition de créer tous les services de base dans une version de ligne de commande d'abord, puis de construire l'interface graphique par-dessus séparément. Cela conduit à l'impossibilité de faire certaines choses sans l'interface graphique, ce qui est l'une des raisons pour lesquelles il y a tant de systèmes de bureau à distance pour Windows, par rapport à Linux : Windows est très difficile à utiliser sans l'interface graphique.

En revanche, il est courant d'administrer à distance des boîtes Unix, BSD, OS X et Linux via SSH. Et comment cela fonctionne-t-il, vous demandez-vous ? SSH connecte un socket réseau (qui est semblable à un fichier) à un pseudo tty à /dev/pty* (qui est de type fichier). Maintenant, votre système distant est connecté à votre système local par une connexion qui correspond si parfaitement à la méthode Unix que vous pouvez faire passer des données par la connexion SSH, si nécessaire.

Avez-vous une idée de la puissance de ce concept maintenant ?

Du point de vue d'un programme, un flux de texte canalisé ne se distingue pas d'un fichier, sauf qu'il est unidirectionnel. Un programme lit à partir d'un pipe de la même manière qu'il lit à partir d'un fichier : à travers un descripteur de fichier. Les FDs sont absolument au cœur d'Unix ; le fait que les fichiers et les pipes utilisent la même abstraction pour les E/S sur les deux devrait vous dire quelque chose.⁹

Le monde Windows, dépourvu de cette tradition de simples communications textuelles, se contente d'interfaces OOP lourdes via COM ou .NET. Si vous devez automatiser un tel programme, vous devez également écrire un programme COM ou .NET. C'est un peu plus difficile que de configurer un pipe sur une machine Unix.

Les programmes Windows dépourvus de ces API de programmation compliquées ne peuvent communiquer qu'à travers des interfaces appauvries comme le presse-papiers ou File/Save suivi de File/Open.

Réponse longue, partie 3 : le registre et les fichiers de configuration.

La différence pratique entre le registre de Windows et la méthode Unix de configuration du système illustre également les avantages de la philosophie "tout est un fichier".

Sur les systèmes de type Unix, je peux consulter les informations de configuration du système à partir de la ligne de commande en examinant simplement les fichiers. Je peux changer le comportement du système en modifiant ces mêmes fichiers. Pour la plupart, ces fichiers de configuration ne sont que des fichiers de texte brut, ce qui signifie que je peux utiliser n'importe quel outil sur Unix pour les manipuler qui peut travailler avec des fichiers de texte brut.

Le scriptage du registre est loin d'être aussi facile sous Windows.

La méthode la plus simple est d'effectuer vos modifications à travers l'interface graphique de l'éditeur de registre sur une machine, puis d'appliquer aveuglément ces modifications aux autres machines avec... regedit via *.reg des fichiers. Ce n'est pas vraiment du "scripting", puisqu'il ne vous permet pas de faire quoi que ce soit de manière conditionnelle : c'est tout ou rien.

Si vos modifications de registre nécessitent une certaine logique, l'option suivante la plus simple est d'apprendre PowerShell, ce qui revient essentiellement à apprendre la programmation système .NET. C'est comme si Unix n'avait que Perl, et que vous deviez faire tout ce que vous voulez. ad hoc l'administration système à travers lui. Maintenant, je suis un fan de Perl, mais tout le monde ne l'est pas. Unix vous laisse utiliser n'importe quel outil que vous aimez, tant qu'il peut manipuler des fichiers de texte brut.


Notes de bas de page :

  1. Le plan 9 a corrigé ce faux pas de conception, en exposant les entrées/sorties réseau via la balise /net système de fichiers virtuel.

Bash a une fonctionnalité appelée /dev/tcp qui permet les entrées/sorties réseau via les fonctions régulières du système de fichiers. Comme il s'agit d'une fonctionnalité de Bash, plutôt que du noyau, elle n'est pas visible en dehors de Bash ou sur des systèmes qui n'utilisent pas du tout Bash. Cela montre, par contre-exemple, pourquoi c'est une si bonne idée de rendre toutes les ressources de données visibles par le système de fichiers.

  1. Par "Windows moderne", j'entends Windows NT et tous ses descendants directs, ce qui inclut Windows 2000, toutes les versions de Windows Server, et toutes les versions de Windows orientées bureau à partir de XP. J'utilise ce terme pour exclure les versions de Windows basées sur DOS, soit Windows 95 et ses descendants directs, Windows 98 et Windows ME, plus leurs prédécesseurs 16 bits.

Vous pouvez voir la distinction par l'absence d'un système d'E/S unifié dans ces derniers OS. Vous ne pouvez pas passer un socket TCP/IP à... ReadFile() sur Windows 95; vous pouvez seulement passer des sockets aux APIs Windows Sockets. Voir l'article fondateur d'Andrew Schulman, Windows 95 : What It's Not pour une plongée plus profonde dans ce sujet.

  1. Ne vous méprenez pas, /dev/null est un véritable périphérique du noyau sur les systèmes de type Unix, et pas seulement un nom de fichier à casse spéciale, comme l'est l'équivalent superficiel NUL dans Windows.

Bien que Windows essaie de vous empêcher de créer un fichier NUL il est possible de contourner cette protection par une simple ruse, en trompant la logique d'analyse du nom de fichier de Windows. Si vous essayez d'accéder à ce fichier avec cmd.exe ou l'Explorateur, Windows refusera de l'ouvrir, mais vous pouvez y écrire via Cygwin, puisqu'il ouvre les fichiers en utilisant des méthodes similaires à celles du programme d'exemple, et vous pouvez le supprimer via une ruse similaire.

En revanche, Unix vous laissera volontiers... rm /dev/nulltant que vous avez un accès en écriture à /dev, et vous laissera recréer un nouveau fichier à sa place, le tout sans trucage, car ce dev node est juste un autre fichier. Tant que ce dev node est manquant, le périphérique nul du noyau existe toujours ; il est juste inaccessible jusqu'à ce que vous recréiez le dev node par le biais de la commande mknod.

Vous pouvez même créer des nœuds dev null device supplémentaires ailleurs : peu importe que vous l'appeliez /home/grandma/Recycle Bintant qu'il s'agit d'un nœud de développement pour le périphérique nul, il fonctionnera exactement de la même manière que /dev/null.

  1. Il y a en fait deux APIs de haut niveau "format disk" dans Windows : SHFormatDrive() et Win32_Volume.Format().

Il y en a deux pour une très... eh bien...Windows une sorte de raison. La première demande à l'Explorateur Windows d'afficher sa boîte de dialogue normale "Formater le disque", ce qui signifie qu'elle fonctionne sur toutes les versions modernes de Windows, mais uniquement lorsqu'un utilisateur est connecté de manière interactive. L'autre peut être appelée en arrière-plan sans intervention de l'utilisateur, mais elle n'a pas été ajoutée à Windows avant Windows Server 2003. C'est vrai, le comportement de base du système d'exploitation a été caché derrière une interface graphique jusqu'en 2003, dans un monde où Unix a livré... mkfs dès le premier jour.

Ma copie d'Unix V5 de 1974 comprend /etc/mkfsun exécutable PDP-11 de 4136 octets à liaison statique. (Unix n'a pas obtenu de liaison dynamique avant la fin des années 1980, donc ce n'est pas comme s'il y avait une grande bibliothèque quelque part ailleurs qui faisait tout le vrai travail). Son code source - inclus dans l'image système V5 sous le nom de /usr/source/s2/mkfs.c - est un programme C entièrement autonome de 457 lignes. Il n'y a même pas de #include d'instructions !

Cela signifie que vous pouvez non seulement examiner ce que mkfs fait à un haut niveau, vous pouvez l'expérimenter en utilisant le même ensemble d'outils avec lequel Unix a été créé, tout comme vous êtes Ken Thompson, il y a quatre décennies. Essayez cela avec Windows. Le plus proche que vous puissiez faire aujourd'hui est de télécharger le code source du DOS, publié pour la première fois en 2014 qui se résume à une pile de sources d'assemblage. Il ne construira qu'avec des outils obsolètes que vous n'aurez probablement pas sous la main, et à la fin vous obtenez votre propre copie de DOS 2.0, un OS bien moins puissant que l'Unix V5 de 1974, bien qu'il soit sorti près de dix ans plus tard.

(Pourquoi parler d'Unix V5 ? Parce que c'est le plus ancien système Unix complet encore disponible. Les versions antérieures sont apparemment perdues dans le temps. Il y avait un projet qui a reconstitué un Unix de l'ère V1/V2, mais il semble qu'il ait disparu... mkfsmalgré l'existence de la page de manuel V1 liée ci-dessus qui prouve qu'il a dû exister quelque part, à un moment donné. Soit ceux qui ont monté ce projet n'ont pas pu trouver une copie de mkfs . mkfs à inclure, ou je suis nul pour trouver des fichiers sans find(1).find(1)qui n'existe pas non plus dans ce système. :))

Maintenant, vous pourriez penser, "Je ne peux pas juste appeler format.com? N'est-ce pas la même chose sous Windows que d'appeler mkfssur Unix ?" Hélas, non, ce n'est pas la même chose, pour un tas de raisons :

- 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. Quand je parle de périphériques de boucle, je ne parle que de Linux plutôt que d'Unix en général, car les périphériques de boucle ne sont pas portables entre les systèmes de type Unix. Il existe des mécanismes similaires dans OS X, BSD, etc, mais la syntaxe varie quelque peu.

  2. À l'époque où les disques durs avaient la taille de machines à laver et coûtaient plus cher que la voiture de luxe du chef de département, les grands laboratoires informatiques partageaient une plus grande proportion de leur espace disque collectif par rapport aux environnements informatiques modernes. La possibilité de greffer de manière transparente un disque distant dans le système de fichiers local a rendu ces systèmes distribués beaucoup plus faciles à utiliser. C'est là que nous obtenons /usr/share, par exemple.

Contrairement à Windows, où un disque distant est généralement soit mappé à une lettre de lecteur, soit accessible par un chemin UNC, plutôt que d'être intégré de manière transparente dans le système de fichiers local. Les lettres de lecteur vous offrent peu de choix pour l'expression symbolique ; est-ce que P: fait-il référence à l'espace "public" sur BigServer, ou au répertoire "packages" sur le serveur miroir de logiciels ? Les chemins UNC signifient que vous devez vous rappeler sur quel serveur se trouvent vos fichiers distants, ce qui devient difficile dans une grande organisation avec des centaines ou des milliers de serveurs de fichiers.

Windows n'a pas obtenu de liens symboliques avant Windows Vista, sorti en 2007, qui a introduit les liens symboliques NTFS. Les liens symboliques de Windows sont un peu plus puissants que les liens symboliques d'Unix - une fonctionnalité d'Unix depuis depuis 1977 - en ce qu'ils peuvent également pointer vers un partage de fichiers distant, et pas seulement vers un chemin local. Unix a fait cela différemment, via NFS en 1984, qui s'appuie sur la fonctionnalité préexistante de point de montage d'Unix, qu'il a depuis le début.

Donc, selon la façon dont vous le regardez, Windows a traîné Unix par environ 2 ou 3 décennies.

Même alors, les liens symboliques ne sont pas une partie normale de l'expérience d'un utilisateur de Windows, pour deux raisons.

Premièrement, vous ne pouvez les créer qu'avec le programme de ligne de commande rétrograde. MKLINK. Vous ne pouvez pas les créer à partir de l'Explorateur Windows, alors que les équivalents Unix de l'Explorateur Windows ont généralement... font vous permettent de créer des liens symboliques.

Deuxièmement, la configuration par défaut de Windows empêche les utilisateurs normaux de créer des liens symboliques, exigeant que vous exécutiez le shell de commande en tant qu'administrateur ou que vous donniez à l'utilisateur la permission de les créer via un chemin obscur dans un outil que votre utilisateur moyen n'a même jamais vu, et sait encore moins comment utiliser. (Et contrairement à la plupart des problèmes de privilèges d'administrateur dans Windows, l'UAC n'est d'aucune aide dans ce cas).

  1. Les boîtes Linux n'utilisent pas toujours une image de disque virtuel dans la séquence de démarrage. Il y a un tas de façons différentes de le faire.

  2. man ed

  3. Les descripteurs de socket réseau sont des FDs en dessous, aussi, d'ailleurs.

Si vous faites défiler vous pouvez trouver les explications des autres chefs de projet, vous avez toujours la liberté de montrer les vôtres si bon vous semble.



Utilisez notre moteur de recherche

Ricerca
Generic filters

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.