Pourquoi le système de fichiers Linux est-il conçu comme une arborescence de répertoires unique?

91

Quelqu'un peut-il expliquer pourquoi Linux est conçu comme une arborescence de répertoires unique?

Alors que dans Windows, nous pouvons avoir plusieurs lecteurs comme C:\, et D:\, il existe une seule racine sous Unix. Une raison spécifique là-bas?

utilisateur2720323
la source
14
@terdon - Je pense qu'il demande d'avoir un seul répertoire racine (/) par rapport au style DOS (C: \ D: \).
Jordanie
27
Vous pouvez (et avez généralement) plusieurs lecteurs sous Linux. En fait, le principe de base est le même C:et D:constitue également un point de montage dans Windows. L'équivalent Windows de /is My Computer, tout est monté en dessous.
terdon
61
Je pense qu'une question plus pertinente serait "pourquoi un système d'exploitation n'aurait PAS une seule racine"? (La réponse pour DOS / Windows serait une erreur de conception / un échec dans la planification de l'avenir / une hypothèse superflue.)
JoelFan
21
Windows a choisi ce système bizarre à cause de MS-DOS avant et MS-DOS a suivi le précédent précédent défini par CP / M. MS-DOS était un système basé sur un lecteur de disquette (A: et B: initialement, parfois par exemple sur un système à un seul lecteur, A: et B: étaient le même lecteur, mais deux disques logiques différents à des fins d’opération d’échange / de copie). . Comme la plupart des personnes endommagées par des PC MS-DOS, l'OP pense que /sous Linux, c'est pareil que C: sous MSDOS / Windows, alors que ce n'est pas vraiment la même chose.
Warren P
25
En fait, C:, D:et d'autres choses est la compatibilité avec le DOS et juste Win32; Windows NT a l' intérieur d' une hiérarchie d'objets un peu comme UNIX, étaient les lettres de lecteur (et en général des choses Win32) ne sont que des liens symboliques vers les objets « réels » ( c:\file.txtest en fait \??\c:\file.txt, avec \??\c:être un lien symbolique , par exemple \device\harddisk0\partition1). Voir par exemple ici
Matteo Italia

Réponses:

192

Étant donné que le système de fichiers Unix est antérieur à Windows depuis de nombreuses années, on peut reformuler la question: "Pourquoi Windows utilise-t-il un code distinct pour chaque périphérique?".

Un système de fichiers hiérarchique présente l'avantage de pouvoir trouver n'importe quel fichier ou répertoire en tant qu'enfant du répertoire racine. Si vous devez déplacer des données vers un nouveau périphérique ou un périphérique réseau, l'emplacement dans le système de fichiers peut rester le même et l'application ne verra pas la différence.

Supposons que vous avez un système où le système d'exploitation est statique et qu'il existe une application avec des exigences d'E / S élevées. Vous pouvez monter / usr en lecture seule et mettre / opt (si l'application y réside) sur des disques SSD. La hiérarchie du système de fichiers ne change pas. C’est beaucoup plus difficile sous Windows, en particulier avec des applications qui insistent pour vivre sous C: \ Program Files \

doneal24
la source
27
Et cette question (rhétorique) a une réponse: la tradition. Juste une tradition différente de celle d'Unix. Windows le reçoit du DOS, qui l’obtient du CP / M-80, qui suivait un schéma commun à de nombreux systèmes d’exploitation pour mini-ordinateurs et ordinateurs centraux. Les noms de lecteur viennent d'être raccourcis de DISK0:ou SY:vers A:.
RBerteig
6
@RBerteig - peut-être la tradition, en particulier dans le cas de Windows, mais Rob Pike présente un argument assez convaincant en faveur de schémas de nommage de style Unix dans The Hideous Name, pdos.csail.mit.edu/~rsc/pike85hideous.pdf
Bruce Ediger
13
Depuis Windows NT, je pense, il a été possible de monter un périphérique sur un chemin virtuel donné de Windows pour accomplir exactement la même chose qu’Unix, bien qu’il soit peu commun sur les ordinateurs domestiques (un peu plus commun sur les serveurs et les déploiements d’entreprise). Vous pouvez choisir de voir ceci comme une confirmation de la manière Unix, si vous le souhaitez.
JSB
8
@BruceEdiger Je ne vais pas essayer de dire que DOS était juste. Nous soulignons simplement qu’il existe un contexte expliquant la raison pour laquelle Windows est ce qu’il est, et que ce n’est pas simplement quelque chose que MS a tiré d’un chapeau.
RBerteig
1
@BruceEdiger: Wow. Beau papier. C'est aussi l'une des rares fois où j'ai vu Pike se tromper indéniablement à propos de quelque chose. (En particulier, le système serveur de noms ARPANET ne peut pas évoluer. De nos jours, nous l'appelons DNS, et il a très bien évolué. Les concepts de base d'un espace hiérarchique absolu avec autorité et délégation restent totalement inchangés). Certes, cela est dû au fait que les réseaux non IP pertinents pour le courrier ont disparu.
Kevin Cathcart
87

C'est en partie pour des raisons historiques et en partie parce que cela a plus de sens de cette façon.

Multics

Multics a été le premier système d'exploitation à introduire le système de fichiers hiérarchique tel que nous le connaissons aujourd'hui, avec des répertoires pouvant contenir des répertoires. Citant «Un système de fichiers polyvalent pour le stockage secondaire» de RC Daley et PG Neumann:

La section 2 du document présente la structure hiérarchique des fichiers, ce qui permet une utilisation flexible du système. Cette structure contient des capacités suffisantes pour assurer la polyvalence. (…)

Pour faciliter la compréhension, la structure de fichier peut être considérée comme une arborescence de fichiers, dont certains sont des répertoires. Autrement dit, à une exception près, chaque fichier (par exemple, chaque répertoire) se trouve directement pointé par exactement une branche dans exactement un répertoire. L'exception est le répertoire racine, ou root, à la racine de l'arborescence. Bien qu'il ne soit explicitement désigné à partir d'aucun répertoire, la racine est implicitement désignée par une branche fictive connue du système de fichiers. (…)

À tout moment, un utilisateur est considéré comme fonctionnant dans un répertoire, appelé son répertoire de travail. Il peut accéder à un fichier effectivement désigné par une entrée de son répertoire de travail en spécifiant simplement le nom de l'entrée. Plusieurs utilisateurs peuvent avoir le même répertoire de travail à la fois.

Comme dans de nombreux autres aspects, Multics recherchait la flexibilité. Les utilisateurs peuvent travailler dans une sous-arborescence du système de fichiers et ignorer le reste, tout en bénéficiant des répertoires pour organiser leurs fichiers. Les répertoires étaient également utilisés pour le contrôle d'accès - l'attribut READ permettait aux utilisateurs de répertorier les fichiers d'un répertoire et l'attribut EXECUTE permettait aux utilisateurs d'accéder aux fichiers de ce répertoire (comme beaucoup d'autres fonctionnalités, conservées sous Unix).

Multics a également suivi le principe d’un seul pool de stockage. Le papier ne s'attarde pas sur cet aspect. Un seul pool de stockage correspond bien au matériel de l'époque: il n'y avait aucun périphérique de stockage amovible, du moins aucun dont les utilisateurs auraient intérêt à se soucier. Multics disposait d'un pool de stockage de sauvegarde distinct, mais celui-ci était transparent pour les utilisateurs.

Unix

Unix s’inspirait beaucoup de Multics, mais visait la simplicité alors que Multics visait la flexibilité.

Un système de fichiers hiérarchique unique convenait parfaitement à Unix. Comme avec Multics, les pools de stockage n'étaient généralement pas pertinents pour les utilisateurs. Cependant, il y avait des périphériques amovibles, et Unix les a exposés aux utilisateurs, via les commandes mountet umount(réservées au «super-utilisateur», c'est-à-dire l'administrateur). Dans «Le système de partage du temps UNIX» , Dennis Ritchie et Ken Thompson expliquent:

Bien que la racine du système de fichiers soit toujours stockée sur le même périphérique, il n'est pas nécessaire que toute la hiérarchie du système de fichiers réside sur ce périphérique. Il existe une demande de système de montage avec deux arguments: le nom d'un fichier ordinaire existant et le nom d'un fichier spécial auquel le volume de stockage associé (par exemple, un pack de disques) doit avoir la structure d'un système de fichiers indépendant contenant sa propre hiérarchie de répertoires. . L'effet de la fonction de montage fait que les références au fichier ordinaire précédent se réfèrent plutôt au répertoire racine du système de fichiers sur le volume amovible. En effet, mount remplace une feuille de l'arborescence de la hiérarchie (le fichier ordinaire) par une nouvelle sous-arborescence (la hiérarchie stockée sur le volume amovible). Après le montage, il n’existe pratiquement aucune distinction entre les fichiers du volume amovible et ceux du système de fichiers permanent. Dans notre installation, par exemple, le répertoire racine réside sur une petite partition de l’un de nos lecteurs de disque, tandis que l’autre lecteur, qui contient les fichiers de l’utilisateur, est monté par la séquence d’initialisation du système. Un système de fichiers montable est généré en écrivant sur le fichier spécial correspondant. Un utilitaire est disponible pour créer un système de fichiers vide ou vous pouvez simplement copier un système de fichiers existant.

Le système de fichiers hiérarchique présente également l’avantage de concentrer la complexité de la gestion de plusieurs périphériques de stockage dans le noyau. Cela signifiait que le noyau était plus complexe, mais que toutes les applications étaient donc plus simples. Comme le noyau doit se soucier des périphériques matériels, mais que la plupart des applications ne le font pas, cette conception est plus naturelle.

les fenêtres

Windows retrace ses origines dans deux lignées: VMS , un système d'exploitation conçu à l'origine pour le mini-ordinateur VAX , et CP / M , un système d'exploitation conçu pour les premiers micro-ordinateurs Intel.

VMS disposait d'un système de fichiers hiérarchique distribué, Files-11 . Dans Fichiers-11, le chemin d'accès complet à un fichier contient un nom de nœud, une désignation de compte sur ce nœud, un nom de périphérique, un chemin d'accès à l'arborescence de répertoires, un nom de fichier, un type de fichier et un numéro de version. VMS possédait une puissante fonctionnalité de nom logique permettant de définir des raccourcis vers des répertoires spécifiques. Les utilisateurs devaient donc rarement se préoccuper de l'emplacement «réel» d'un répertoire.

CP / M a été conçu pour les ordinateurs dotés de 64 Ko de RAM et d’un lecteur de disquette. La simplicité s’imposait. Il n'y avait pas de répertoires, mais une référence de fichier pouvait inclure une indication de lecteur ( A:ou B:).

Lorsque MS-DOS 2.0 a introduit les répertoires, il l'a fait avec une syntaxe compatible avec MS-DOS 1 qui suivait elle-même CP / M. Ainsi, les chemins ont été enracinés sur un lecteur avec un nom composé d'une seule lettre. (De plus, la barre oblique /était utilisée dans VMS et CP / M pour démarrer les options de ligne de commande. Il fallait donc utiliser un autre caractère comme séparateur de répertoire. C’est pourquoi DOS et Windows utilisent la barre oblique inversée, bien que certains composants internes prennent également en charge les barres obliques. )

Windows conservait la compatibilité avec les approches DOS et VMS et conservait donc la notion de lettres de lecteur, même lorsqu'elles devenaient moins pertinentes. Aujourd'hui, sous le capot, Windows utilise des chemins UNC ( développés à l'origine par Microsoft et IBM pour OS / 2 , d'ascendance associée). Bien que cela soit réservé aux utilisateurs expérimentés (probablement en raison du poids de l'historique), Windows autorise le montage via des points d'analyse .

Gilles
la source
3
Bien que ce ne soit pas le comportement par défaut, avec les systèmes de fichiers NTFS, Windows peut également monter tout votre stockage sous une seule racine: technet.microsoft.com/en-us/library/cc753321.aspx howtogeek.com/98195/… serverfault.com/questions / 24400 /…
gerlos
3
Il semble que la partie pertinente est que MS-DOS 1.0 était basé sur une disquette. Sur un tel système, (a) il était important de savoir sur quel disque physique se trouvaient vos fichiers et (b) A:et B:constituait une convention décente pour distinguer vos lecteurs de disquettes si vous en possédiez deux. Lorsque la prise en charge de disque dur a été ajoutée dans MS-DOS 2.0, la C:désignation du lecteur permettait une compatibilité ascendante en considérant le disque dur comme une seule disquette BIG.
user1024
5
En fait, initialement, CP / M a été conçu pour fonctionner avec 16 Ko, et non 64 Ko de RAM. Le chiffre de 64 Ko est probablement destiné à laisser un peu de marge de manœuvre aux applications ; pendant que le processeur de commandes (CCP) était écrasé et rechargé si nécessaire, le BIOS et le BDOS résidaient en permanence dans la mémoire. Eh oui, c'est de là que vient le BIOS - IBM n'a pas inventé le terme! Voir Wikipedia CP / M: Modèle matériel et Composants du système d'exploitation . N'oubliez pas que 16 Ko ne représentent qu'environ trois pages d'écriture dense (70 lignes × 80 caractères / ligne × 3 pages = 16800 octets).
un CVn
36

Il n'y a pas de problème de sécurité derrière une arborescence de répertoires unique.

Les concepteurs de Unix possédaient une grande expérience des systèmes d’exploitation, qui obligeaient les utilisateurs à savoir quel périphérique physique contenait une ressource donnée. Étant donné qu'une partie du but d'un système d'exploitation est de créer une machine abstraite au-dessus d'un matériel réel, ils ont trouvé beaucoup plus simple de se passer des ressources d'adressage par leur emplacement physique et ont décidé de tout mettre dans une seule arborescence de noms.

Ceci n'est qu'une partie du génie derrière la conception d'Unix .

msw
la source
28

Notez que les noms de lettre de lecteur de MS-DOS qui persistent dans Windows moderne constituent ici un fil rouge. Les noms de lettre de lecteur ne sont pas la meilleure représentation d'une structure de système de fichiers ayant plusieurs racines. Ils sont une implémentation d'un tel système.

Un système de fichiers correctement implémenté qui prend en charge plusieurs racines autoriserait l'attribution de noms arbitraires aux volumes, comme dvdrom:/path/to/file.avi. Un tel système permettrait de se débarrasser des problèmes d’interface utilisateur risibles qui minent Windows. Par exemple, si vous connectez un périphérique tel qu'un appareil photo, l'interface utilisateur de Windows Explorer vous fait croire qu'il existe un périphérique appelé Appareil photo (ou autre) et que vous avez un chemin similaire à Computer\Camera\DCIM\.... Toutefois, si vous coupez et collez la version textuelle de ce chemin dans Explorer, cela ne fonctionne pas, car certains composants du chemin d'accès constituent une fiction de l'interface utilisateur, inconnue du système d'exploitation sous-jacent. Dans un système correctement mis en place avec plusieurs racines, cela irait: il y aurait unecamera:\DCIM\...chemin qui est reconnu uniformément à tous les niveaux du système. En outre, si vous portiez un ancien disque dur à partir d’un ancien ordinateur, vous ne seriez pas bloqué avec un nom de lettre de lecteur du type F:, mais vous pourriez plutôt le nommer comme vous le souhaitez old-disk:.

Donc, si Unix avait plusieurs racines dans la structure du système de fichiers, cela se ferait de la manière la plus appropriée, et non comme dans MS-DOS et Windows avec des noms de lecteur à une lettre. En d'autres termes, comparons uniquement le schéma Unix à un bon design multi-racine.

Alors, pourquoi Unix n’a-t-il pas une implémentation saine à plusieurs racines, en faveur d’une implémentation saine à une racine? C'est probablement juste pour la simplicité. Les points de montage fournissent toutes les fonctionnalités permettant d'accéder aux volumes via des noms. Il n'est pas nécessaire d'étendre l'espace de noms avec une syntaxe de préfixe supplémentaire.

Mathématiquement, tout graphe d’arbre disjoint ("forêt") peut être joint en ajoutant un nœud racine et en transformant les morceaux disjoints en ses enfants.

De plus, il est plus flexible que les volumes ne soient pas obligatoirement au niveau racine. Comme il n’existe pas de syntaxe spéciale indiquant le volume (c’est juste un composant de chemin), les points de montage peuvent être n’importe où. Si vous apportez trois anciens disques sur votre ordinateur, vous pouvez les avoir comme /old-disk/one, /old-disk/two, etc. Vous pouvez organiser des disques comme vous le voulez, la façon dont vous organisez des fichiers et des répertoires.

Il est possible d’écrire des applications qui dépendent de chemins, et la validité de ces chemins peut être conservée lors de la reconfiguration des périphériques de stockage. Par exemple, les applications peuvent utiliser des chemins d'accès connus tels que /var/loget /var/lib. Il est à vous si /var/loget /var/libsont sur le même volume de disque ou sur les séparés. Vous pouvez migrer un système vers une nouvelle topologie de stockage tout en préservant les chemins.

Les points de montage sont une bonne idée, c'est pourquoi Windows les utilise depuis Windows 2000 environ.

Les points de montage de volume sont robustes face aux modifications du système qui surviennent lorsque des périphériques sont ajoutés ou supprimés d'un ordinateur. Microsoft Technet

Kaz
la source
6
Peut-être par hasard, votre "bonne conception multi-racine" ressemble beaucoup à l'ancien système AmigaDOS , qui autorisait des noms de volume arbitraires, y compris des volumes "assignés" faisant référence à un répertoire spécifique à l'intérieur d'un autre volume. Vous pourriez même (avec un logiciel approprié ) avoir des volumes "virtuels" comme, par exemple, un FTP:volume qui vous permettait d'accéder aux fichiers sur n'importe quel serveur FTP avec un chemin tel que FTP:hostname/path/to/file.
Ilmari Karonen
3
Ce n'est vraiment pas une bonne réponse car cela semble extrêmement subjectif. Sa jolie ouvertement Windows bashing.
Rig
3
@Rig Bien que cela puisse être vrai, Windows mérite un traitement complet pour avoir toujours ces noms de lettre de lecteur, remontant à MS-DOS. Il s'agit du système de fichiers à plusieurs racines avec lequel la plupart des utilisateurs sont familiarisés, mais nous ne pouvons pas vraiment l'utiliser à des fins de comparaison avec une seule racine, car il s'agit d'un exemple parfait d'un tel système.
Kaz
3
@Kaz, je trouve toujours que cette réponse est plus un coup de gueule. Windows rend le système de fichiers différent, mais cela ne le rend pas faux, horrible ou un crime contre l'humanité. Vous n'aimez pas ce que vous avez le droit. Microsoft n'a même pas mis au point ce schéma, il l'a emprunté à un système populaire du jour, mais il doit le maintenir pour une maintenabilité raisonnable avec le code hérité.
Rig
1
@Rig Sure; ce n’est pas plus terrible que, par exemple, d’obtenir votre prochain dîner au moyen d’une pointe de flèche en silex. Les flèches en silex étaient à la pointe de la modernité . Ah, mais oups, on ne peut pas vraiment dire ça à propos du DOS et des lettres de lecteur, on peut ... autant pour les analogies.
Kaz
13

* Nix et Windows montent leurs lecteurs. Sous Windows, ceux-ci sont automatiquement montés dans des points de montage qui, par défaut, sont classés par ordre alphabétique croissant. Ces valeurs par défaut sont:

  • A:et B:=> disquettes
  • C: => première partition du premier disque dur
  • D: => prochaine partition ou prochain disque dur ou lecteur de CD / DVD si aucune autre partition n'est présente.

Chacun de ces points de montage est un répertoire.

Dans * nix, les points de montage sont déterminés par l'utilisateur. Par exemple, une partition est montée en tant que /et une autre en tant que /home. Donc, /homeest un lecteur séparé, ce serait l'équivalent de dire E:sous Windows.

Dans les deux cas, Windows et * nix, les points de montage sont des répertoires distincts. La seule différence est que dans * nix, ces répertoires distincts sont des sous-répertoires de /, C:alors que dans Windows, chaque point de montage est monté directement sous le /sous, My Computerpar exemple.

Du point de vue de l'utilisateur, le principal avantage est que les montages sont complètement transparents. Je n'ai pas besoin de savoir que le répertoire /homeest en fait sur une partition séparée. Je peux juste l'utiliser comme un répertoire normal. Au lieu de cela, dans DOS, je devrais l'appeler explicitement par le nom du point de montage, disonsE:\home

Les disques externes sont montés à peu près de la même manière dans les deux systèmes. Dis D:pour Windows et /mnt/cdrompour Linux. Chacun de ceux-ci est un répertoire, je ne vois pas vraiment la différence. Lorsque vous insérez un CD-ROM dans votre lecteur sous Windows, le disque est monté D:comme dans Linux.

terdon
la source
3
Par curiosité, savez-vous ce qui se passerait si quelqu'un voulait créer 27 lecteurs sous Windows? Comment Windows appellerait-il le 27e lecteur? : D
Joseph R.
2
Hahaha. Semble que Windows est trop ennuyeux pour le faire.
Joseph R.
3
Nitpick mineure: les lettres de lecteur dans Windows par défaut à l' ordre alphabétique croissant, mais ils peuvent être et sont souvent renommés.
RBerteig
3
@terdon: il monte simplement le lecteur dans un répertoire - exactement comme vous le faites dans les systèmes d'exploitation POSIX.
Matteo Italia
3
@JosephR: À un moment donné - je ne sais pas quand, mais probablement NT - Windows a pu monter des lecteurs dans des répertoires, un peu comme Unix. Par défaut, personne ne le fait réellement (ce qui me surprend: avec la fréquence des réinstallations nucléaires, je pense que quelque chose d'analogue à mettre / home sur un volume séparé serait devenu populaire maintenant). Toutefois, si vous manquez de lettres, de chiffres et de symboles de lecteur, vous devez le faire si vous souhaitez ajouter davantage de lecteurs au système.
Le Spooniest
10

Je suis d'accord avec les réponses ci-dessus, en particulier celle de Doug O'Neal, mais je pense qu'elles manquent toutes un petit quelque chose, tout comme les points de montage de périphériques explicites tels que "C:" ou "A:" de MS-DOS.

Rob Pike a écrit The Hideous Name sur la syntaxe des noms, mais Russ Cox l'a résumé :

Les espaces de noms ... sont plus puissants lorsque de nouvelles sémantiques peuvent être ajoutées sans ajouter de nouvelle syntaxe.

Un seul espace de noms sur lequel les périphériques peuvent être montés à volonté permet des opérations vraiment flexibles. J'utilise régulièrement /mnt/sdb1et /mnt/cdromplace temporairement un disque ou un CD non utilisé dans le système de fichiers global. Il n'est pas rare de posséder des répertoires de départ sur un serveur NFS, de sorte que peu importe la machine à laquelle vous vous connectez, vous obtenez la même chose $HOMEpartout.

Cela revient à ceci: avoir une syntaxe spéciale pour des choses spéciales impose des limites précises à ce que vous pouvez faire. Si vous ne pouvez monter qu'un disque ou un CD ou un DVD inutilisé, ou un système de fichiers réseau / "partager" sur "E:" ou "W:" ou autre, vous avez beaucoup moins de flexibilité.

Bruce Ediger
la source
1
Vous n'avez pas vraiment besoin de liens symboliques pour cela. Vous pouvez monter directement une partition (ou un stockage réseau ou autre) sur n’importe quel chemin, tel que / usr / local - bien que cela me dérange toujours lorsque je trouve un réseau où / usr / local pointe sur un montage réseau. Oui, ils existent et il y a une raison de le faire: / usr / local est l'un des emplacements standard permettant à votre administrateur de placer des éléments autres que ceux du distributeur de système d'exploitation.
Christopher Creutzig
@Christopher Creutzig - Je suis d'accord, le lien symbolique n'est pas nécessaire pour mon exemple, je voulais juste vous donner un autre exemple de la manière dont un schéma de dénomination flexible peut fonctionner pour vous. Ce n'est peut-être pas le meilleur exemple.
Bruce Ediger
Regardez le stupide Web, au fait. proto://specifichost.domain.tld/topleveldir/middle/specificdoc.html.
Kaz
2
@Christopher Creutzig - J'ai installé / usr / local en tant que lecteur réseau à plusieurs endroits. "local" signifie alors local sur le site, pas sur la machine.
Doneal24
3
@ Kaz, je pense que l' proto://entreprise est une nécessité pragmatique. On ne peut pas s'attendre à ce que chaque logiciel connaisse tous les schémas d'URI existants. Ainsi, il peut être utile de savoir quand l'ID de schéma se termine et le reste de l'URI commence.
Adrian Ratnapala
5

C'est idiot. Windows a également un seul point de hiérarchie. Mais c'est caché et non standard. Comme la plupart des choses Windows.

Dans ce cas, il s’agit du concept "Poste de travail". C'est l'équivalent de root (/) sous Unix. Rappelez-vous que la racine est un concept qui existe dans le noyau. tu l'aimes ou pas. Tout comme Windows traite le "Mon ordinateur". bien sûr, vous pouvez monter une partition sur root sous Unix, et c'est ce que font la plupart des gens. Et beaucoup de choses regarderont un chemin spécifique (par exemple / etc /) mais vous n’êtes pas limité par cela. Bien sûr, montez vos lecteurs dans / C: /. vous n'êtes pas interdit de le faire sous unix.

C: \ n’est pas une racine dans Windows, c’est le point de montage d’une partition. Ce qui DOIT être au plus haut niveau "Mon ordinateur". Sous UNIX, vous pouvez monter une partition sous n’importe quel arbre. Vous pouvez donc installer C: dans Linux et /D: dans /mnt/d/... ou même également, /mais cela est délicat et dépend de la façon dont les deux systèmes de fichiers se comportent lors du montage sur un chemin déjà monté.

Vous pouvez donc obtenir exactement la même chose que vous avez avec Windows en vous "obligeant" à respecter les mêmes limites que Windows vous impose de manière aléatoire.

/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)

Ensuite, vous devrez passer dans les options de montage sur les options de démarrage. puisque vous n’avez pas de / etc / ... mais que cela simule aussi les limitations que Windows impose, comme ce que ça fait.

gcb
la source
4
Windows a une seule hiérarchie sous le capot, et même des points de montage, mais il ne les utilise pas par défaut.
Gilles
1
@ Gilles pas sûr de comprendre. Comment attacher chaque pilote au nœud racine "Poste de travail" ne l'utilise pas par défaut?
GCB
5
C'est la présentation graphique uniquement. Les chemins de fichiers n'utilisent pas My Computer.
Gilles
3
My Computerest le nœud racine de la hiérarchie du shell. il contient des lecteurs, s'ils ont une lettre de lecteur , mais également le panneau de commande et tout Windows Phone connecté. La hiérarchie du shell utilise les PIDL au lieu des chemins.
MSalters
4
@gcb: le fait est que la hiérarchie du shell n'est pas directement utilisable dans les applications "normales". Vous ne pouvez pas appeler en CreateFilepassant "Poste de travail" ou d’autres dossiers du shell; c'est une abstraction comprise uniquement par le code lié au shell, tous les appels du noyau (et donc 90% des applications, puisque la gestion des fichiers dans la plupart des langues est implémentée en termes d'API de fichier du noyau) ne connaissent rien de tout cela. Les dossiers shell ne sont utilisables que lorsque les programmes utilisent les "dialogues standard" (qui comprennent l’espace de noms du shell) et uniquement lorsque les fichiers sélectionnés mappent directement sur un chemin "réel" (= compris par le noyau).
Matteo Italia
5

La raison pour laquelle Windows a des lettres de lecteur remonte probablement plus loin que Microsoft et DOS. L'affectation de lettres à des lecteurs amovibles était courante sur les systèmes IBM. Microsoft a donc peut-être simplement suivi les instructions d'IBM en copiant CP / M. Et au début, de toute façon, DOS n’avait pas de répertoires.

Lorsque MS-DOS s'exécutait sur des ordinateurs avec un ou deux disques amovibles et aucun support fixe, vous n'aviez pas vraiment besoin d'un système de fichiers avec des répertoires. Avec un, ou peut-être deux, disques de 180 kilo-octets, vous n’avez jamais eu assez de fichiers pour avoir beaucoup de difficulté à les organiser.

https://en.wikipedia.org/wiki/Drive_letter_assignment

david25272
la source
1
C'est inexact au mieux. CP / M a précédé tous les DOS Microsoft / IBM-PC de plusieurs années (je crois que l’idée originale d’IBM était d’utiliser CP / M pour leur "PC", car il s’agissait d’un standard industriel de facto assez bien établi à l’époque. le fait que différents systèmes CP / M puissent être incompatibles), et il n’est guère contesté que le DOS IBM-PC reposait lourdement sur le DOS-86, qui était à son tour un clone compatible CP / M compatible avec le code source .
un CVn
4

En réalité, Linux est basé sur Unix (ou Unix, voir la discussion ) et Unix provient d'un environnement mainframe, où l'utilisation de plusieurs périphériques était assez évidente. Le montage de périphériques dans une arborescence de répertoires unique vous offre une flexibilité maximale et ne limite pas le nombre de périphériques auxquels le système d'exploitation peut accéder.

De l’autre côté, les lettres DOS pour les lecteurs sont bien conçues pour un PC avec 1 ou 2 stations de disquette et un seul lecteur de disque. La grande disquette 5,25 'est toujours A :, la petite 3,5' est toujours B: et le lecteur est toujours C :. Vous savez toujours si vous copiez un fichier sur la disquette ou quelque part sur le disque. Vous n'avez besoin d'aucune flexibilité si vous ne pouvez pas connecter physiquement plus de 2 lecteurs de disquettes et 2 (ou 4) disques durs.

La conception DOS était plus conviviale pour les utilisateurs finaux, tandis que la conception Unix était conviviale pour les administrateurs. Maintenant, les lettres de lecteur sont un fardeau pour Windows, les utilisateurs dépendent davantage de l'ouverture automatique de la fenêtre de l'explorateur avec le contenu du lecteur amovible que de la connaissance de sa lettre ... Ubuntu en fait de même.

Marin danubien
la source
1

Ce n'est pas vrai, en fait. Windows utilise un autre schéma de chemins (enfin, pas le même)

Les "lettres d'unité" ne sont que des éléments à retenir, tels que chemins, disques et partitions.

Les chemins ARC définissent le chemin d'un fichier dans Windows (mais ils ne sont visibles à l'utilisateur qu'au démarrage):

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows

Dans Windows NT, il n'y a pas de relation entre les disques, les partitions et les lettres d'unité: vous pouvez "mettre" un volume entier dans un dossier (par exemple: c: \ myseconddisk pourrait être un disque physique entier!)

AndreaCi
la source
1
Les chemins ARC servent uniquement au démarrage et à la compatibilité avec certaines ROM lorsque NT a été porté sur Alpha et MIPS. Lorsque le système est en cours d'exécution, il utilise des chemins UNC.
Ninjalj
0

Deux choses que je voudrais souligner -

  1. Les disques durs sous Linux sont en quelque sorte des lettres / noms assignés, comme / dev / sdb1. Mais ils peuvent être montés n’importe où pour être atteints à partir de la structure unique / racine
  2. La raison la plus courante pour les personnes (y compris moi-même dans le passé) avaient des lecteurs distincts dans Windows était de pouvoir conserver des documents, de la musique, des programmes, etc. défaillance du système de fichiers, il y avait toujours un accès à ces fichiers. Je n'ai pas ce problème sous Linux - le système de fichiers est beaucoup plus fiable, le système d'exploitation ne se casse pas, sauf par une action directe ou une erreur de ma part (ouh! Un repo à la fine pointe, essayons ça!), Et des mises à jour sont loin plus simples. Et, dans les rares cas où j'ai eu à réinstaller, puisque tous les logiciels étaient disponibles via des pensions ou des PPA que j'ai ajoutés (et je pouvais facilement copier mon répertoire personnel avec un disque live),
Drake Clarris
la source
2
Vous combinez des disques durs et des systèmes de fichiers dans votre premier point. Si vous montez / dev / sdb1 à un moment donné du système de fichiers, vous pouvez accéder aux fichiers du lecteur. Si vous ouvrez directement / dev / sdb1, vous verrez les blocs de disque bruts. Généralement pas très utile, surtout si vous utilisez des systèmes de fichiers cryptés.
doneal24
J'essayais de faire le lien d'une manière que les utilisateurs de Windows pourraient comprendre. C: ce n'est pas un disque dur sous Windows non plus, mais tout le monde le dit
Drake Clarris
1.Vous pouvez toujours conserver vos fichiers sans lettre. 2.Sur les systèmes POSIX, un disque dur peut être partitionné dans son ensemble sans table de partition, et une clé USB peut avoir une table de partition. Nom.
Behrooz
0

Si vous parcourez l'historique, vous pouvez également constater qu'Unix a démarré à l'époque des systèmes de bande à 8 pistes pour les systèmes de données audio et IBM à 9 pistes (8 pistes / 8 bits pour les données, une pour la parité). Techniquement très identique.

À ce moment, les informations sur l'emplacement des fichiers étaient stockées dans des parties de l'information sur la bande et définies avant et arrière lorsque vous lisiez des données sur la bande (comme un fichier, avec position de départ et signature de fin); cela explique également pourquoi vous n'aviez pas un seul FAT au début du lecteur, mais plusieurs pour accélérer la recherche. Et si vous aviez plusieurs lecteurs, ils étaient liés à l'intérieur de / dev et via l'adresse du fichier que vous avez déplacé entre les périphériques.

Je pense que vous pourriez penser que cela a commencé tout simplement plus tôt et que la décision derrière la zone MS Dos (CP / M) et plus tard Windows NT est simplement liée aux lettres de lecteur de l'ordinateur central VM au lieu d'un point d'entrée unique, car à l'époque plus modernes, les données actuelles n’existaient pas et ils ne pensaient pas que vous finiriez par ne plus avoir suffisamment de lettres de lecteur ou qu’il serait encombré.

Affectation 9-Track-Drive et lettre de lecteur

Peter
la source