1 votes

Quels sont les protocoles/normes sous-jacents à un chemin de fichier Windows" par opposition à un chemin de fichier Linux de type NFS?

C'est probablement une question très mal formulée, mais c'est la taxonomie de cette question que je cherche (donc malheureusement, à ce stade, je ne peux pas l'aider).

Voici ma question.

Nous ne nous promenons pas en appelant la représentation du système de fichiers pour Centos "Chemins de fichiers Centos", de même que nous n'appelons pas le système de fichiers dans Ubuntu "Chemins de fichiers Ubuntu" ou même "Chemins de fichiers Linux" - je vois généralement ces derniers désignés comme des chemins NFS (que cela soit correct ou non).

J'entends cependant les utilisateurs de Windows faire référence à la représentation du système de fichiers (avec des lettres de lecteur) comme "Chemins de fichiers Windows". Donc je demande "Qu'est-ce qu'un chemin de fichier Windows"? Par là, je veux dire quels sont les concepts et protocoles sous-jacents qui régissent ce qu'est un chemin de fichier Windows.

Pour plus de clarté, voici quelques exemples. À ma connaissance, ce que je désigne comme un chemin NFS (que cela soit correct ou incorrect) ressemble à ceci :

  

/etc/some-other-dir

où chaque niveau/répertoire est séparé par /

Ma taxonomie naïve pour "chemin Windows" ressemble à quelque chose comme ceci :

  

c:\some-dir\some-child-dir

Donc par défaut, quand je passe à l'une des différentes variantes de Linux que j'utilise (Centos, Ubuntu), je les appelle généralement des chemins NFS. Quand je passe à Windows, je l'appelle un "Chemin Windows". Je sais qu'il existe des protocoles et des normes qui gouvernent probablement ce mappage du système de fichiers (par exemple, ce qui mappent c:\some-dir à des sections d'un disque), et Google m'a dirigé vers CIFS/SMB décrit ici : http://en.wikipedia.org/wiki/Cifs

Mais cela semble décrire des chemins réseau Windows. J'ai également vu le "schéma de nommage des lecteurs" ici - http://en.wikipedia.org/wiki/DOS#Drive_naming_scheme - mais cela ne répond pas vraiment à ma question. Quand je passe sur ma machine Windows, qu'est-ce qui définit précisément un chemin Windows ? Plus précisément, quand je spécifie c:\some-dir\some-child-dir, quels protocoles et normes sont utilisés par le système d'exploitation pour pointer cette adresse vers une partie de mon disque dur ? Supposons que nous parlons de Windows 7 (bien que je sois également intéressé de savoir si Windows 7 le fait différemment des autres versions de Windows).

Je sais que c'est probablement une question de débutant et que la réponse est probablement très facile à trouver avec les bons mots-clés, mais la frustration de ne pas savoir commence à me peser.

Pas de réponses "Il suffit de chercher sur Google" s'il vous plaît - j'ai fait cela de manière extensive et cela semble juste soulever davantage de questions. Je recherche une explication technique ici.

3voto

munaz Points 23

Pratiquement tous les systèmes modernes utilisent un système de fichiers prenant en charge une structure hiérarchique -- un niveau de base, avec des dossiers contenant d'autres dossiers (et ainsi de suite), certains contenant des fichiers.

Le choix du caractère utilisé dans l'interface pour vous indiquer où vous vous trouvez est assez arbitraire ; les systèmes basés sur UNIX utilisent le slash (/), ceux dérivés de DOS utilisent le backslash (\) -- MSDN propose un peu de contexte sur ce choix -- alors que les anciens Mac pré-OSX utilisaient le deux-points (:).

DOS (et les descendants, jusqu'à NT) attribuaient des identifiants à une seule lettre à tous les périphériques de stockage (et aux éléments les imitant). À l'origine, il y avait de la place pour 2 lecteurs de disquettes (A: et B:), donc le disque dur est devenu C: et est resté ainsi par tradition (à tel point qu'un nombre surprenant de programmes cessent de fonctionner si vous modifiez la lettre de votre disque de démarrage.)

Avec NT, la plupart des besoins en coulisses de rendre le lecteur C: obligatoire ont été éliminés, et la possibilité de monter un autre périphérique de stockage en tant que répertoire sous C: a été ajoutée. Cela le rapproche un peu du fonctionnement UNIX : le lecteur de démarrage est monté en '/', et divers autres lecteurs peuvent être montés en tant que répertoires en dessous (/home, /usr, /tmp, comme vous le souhaitez).

Lorsque DOS a découvert les réseaux, ils ont abandonné les lettres de lecteur pour les périphériques distants, ce qui vous donne un chemin de style UNC : \serveur\nomdufichier\repertoire\fichier.txt. Le nom du fichier est simplement un nom pour le répertoire de base du côté serveur, et il est assez courant que le nom du fichier corresponde au nom du répertoire de niveau supérieur du partage, mais ce n'est pas une obligation.

Lorsque vous restez dans le cadre d'UNIX-à-UNIX ou de Windows-à-Windows, c'est simple, il suffit de garder le slash ou le backslash partout pareil, et le tour est joué. Lorsque vous passez d'un système à l'autre, les choses se compliquent. La plupart des programmes conservent la syntaxe de la plate-forme sur laquelle ils s'exécutent, même lorsqu'ils accèdent (probablement sans le savoir) à quelque chose provenant de l'autre plate-forme. Certaines applications -- spécifiquement conçues pour la compatibilité multiplateforme ou pour faciliter l'utilisation -- préfèrent que leurs entrées soient dans le format souhaité pour l'autre plate-forme. Cela devient compliqué : les shells UNIX utilisent le backslash comme caractère d'échappement ; vous devez taper '\\' pour envoyer un simple backslash en entrée à une commande UNIX en tant qu'option de ligne de commande.

Tout cela, bien sûr, concerne principalement l'interface utilisateur. En coulisses, un fichier est réellement identifié par (essentiellement) un numéro (les systèmes UNIX l'appellent un inode), et le système de fichiers est responsable de suivre quelles noms (éventuellement multiples, dans différents répertoires, en cas de liens physiques) sont associés au même inode, et quels secteurs de disque composent le contenu du même inode).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X