Sur quels systèmes // foo / bar est-il différent de / foo / bar?

114

Dans toute la spécification POSIX, il est prévu ( 1 , 2 , 3 ...) de permettre aux implémentations de traiter un chemin commençant par deux /spécialement.

Une application POSIX (une application écrite dans la spécification POSIX pour être portable sur tous les systèmes compatibles POSIX) ne peut pas supposer qu'elle //foo/barest identique à /foo/bar(bien qu'elle puisse supposer qu'elle ///foo/barest identique à /foo/bar).

Maintenant, quels sont les systèmes POSIX (historiques et toujours maintenus) qui traitent //foospécialement? Je pensais (je me suis maintenant trompé ) que Microsoft avait mis à disposition POSIX pour la variante Unix (XENIX) et éventuellement la couche Windows POSIX (quelqu'un peut-il confirmer cela?).

Il est utilisé par Cygwin, qui est également une couche de type POSIX pour Microsoft Windows. Existe-t-il des systèmes autres que Microsoft Windows? OpenVMS?

Sur //foo/barquels systèmes est spécial, à quoi sert-il? //host/pathpour l'accès aux systèmes de fichiers réseau? Systèmes de fichiers virtuels?

Certaines applications fonctionnant sous Unix-like - si ce n’est pas l’API du système - traitent-elles //foo/barspécialement les chemins (dans des contextes où elles le traitent autrement /foo/barcomme chemin du système de fichiers)?

Modifier , je l' ai depuis posé une question sur la liste de diffusion groupe austin sur l'origine de la //foo/barmanipulation dans les spécifications, et la discussion est une lecture intéressante (d'un point d'archéologie de vue au moins).

filenames  history  portability  slash 
— Stéphane Chazelas
source
1
— Stéphane Chazelas
1
@OlivierDulac, n ° ls -ld ///afficherait également ///, lsjuste affiche le fichier , il est dit à afficher comme il a été donné. Je recherche des systèmes ou des applications qui traitent // foo / var spécialement (pas comme un chemin sur le système de fichiers) comme Cygwin.
— Stéphane Chazelas
1
standard ( pubs.opengroup.org/onlinepubs/009695399/basedefs/… ) dit, comme vous l'avez mentionné, "un chemin qui commence par deux barres obliques successives peut être interprété de manière définie par l'implémentation" (plus de 2 se résout à 1 /) . Un exemple trouvé sur le net: austingroupbugs.net/view.php?id=83 ( IBM's z/OS resolves //pathname requests to MVS datasets (as opposed to the hierarchical filesystem (HFS)) (......) Additionally, z/OS would not accept or recognize additional "directory" or "file" components appended to such paths.... pas exactement unix, bien que ^^).
— Olivier Dulac
4
@DevSolar: vraiment interressant (et surprenant), mais nous ne devrions nous en tenir qu'à POSIX, car tout est possible avec POSIX ^^
— Olivier Dulac le
2
@edwardtorvalds parce que le premier bit est l'URL file://:, semblable à http://, etc. Sur chrome ici au travail un chemin Windows UNC que je suis ouvert est maintenant file:////$MACHINE/$SHARENAME/index.html(bien que pour une raison quelconque il comprend également file://$MACHINE/...)
— admalledd

Réponses:

90

Ceci est une compilation et un index des réponses données jusqu'à présent. Cet article est un wiki de communauté , il peut être édité par n'importe qui ayant plus de 100 ans de réputation et personne n'en tire de réputation. N'hésitez pas à poster votre propre réponse et à ajouter un lien vers celle-ci (ou attendez que je le fasse). Idéalement, cette réponse devrait simplement être un résumé (avec des entrées courtes tandis que les réponses individuelles auraient les détails).

Systèmes actuellement activement maintenus:

Systèmes défunt

Applications qui traitent //foo/barspécialement pour les chemins

— Stéphane Chazelas
source
3
L'utilisation de l' //espace de noms a été proposée par certains développeurs du noyau Linux pour les installations de métadonnées de Reiser4, mais je ne pense pas que cette proposition ait gagné du terrain au sein de Namesys et qu'elle n'ait jamais été mise en œuvre.
— Jörg W Mittag
Windows lui-même implémente l'API POSIX ... comment cela gère-t-il une double barre oblique?
— Kevin
1
Nous pouvons ajouter que sur le Web, les ressources commençant par une double barre oblique définissent une racine différente de celle utilisée par la barre simple.
— Alex Gittemeier
@ Kevin, oui, je le crois aussi (voir la question), bien qu'il s'agisse d'un composant facultatif et uniquement sur certaines variantes de Windows et maintenant abandonné. Si vous avez plus de détails, veuillez ajouter une réponse.
— Stéphane Chazelas
@ AlexGittemeier. Oui, vous remarquerez qu'il est effectivement utilisé dans cette réponse ;-).
— Stéphane Chazelas
16

Certaines applications fonctionnant sous Unix-like - si ce n'est l'API du système - traitent-elles spécialement // foo / bar Paths?

Je suis au courant de Perforce qui utilise //depot/A/B/C/DPaths pour se référer au Dépôt. Perforce prend également en charge les //Client/C/Dchemins, lorsque le client pointe vers //depot/A/B/. Ici, le système de fichiers local peut ne pas avoir ces chemins.

p4 filelog //depot/A/B/C/Dmontrera l'historique de ce fichier, même s'il n'y a pas de fichier /depot/A/B/C/D.

p4 filelog C/D affichera également l'historique de ce fichier, s'il est exécuté à partir du répertoire approprié.

Référence: https://www.perforce.com/perforce/r12.1/manuals/cmdref/o.fspecs.html

— Prem
source
13

Il y a plusieurs décennies, Tektronix Utek (Unix basé sur BSD 4.2, d'abord sur les processeurs National Semiconductors 32016, puis sur Motorola 68020 ) fournissait quelque chose appelé DFS (système de fichiers distribué) sous lequel //foo/barse référait au /barfichier sur le fooserveur DFS. Il a ensuite été rendu obsolète par NFS de Sun.

Malheureusement, je n'ai pas encore fait référence à cela, mais je pourrais éventuellement trouver de la documentation Utek dans ma cave et mettre à jour cette réponse.

— jlliagre
source
1
Corroborée par cette discussion usenet
— Stéphane Chazelas
@ StéphaneChazelas Je pense que ce lien avec Usenet est meilleur. Celui que vous choisissez a Domain / OS mais pas Utek. Ou le message suivant (du vôtre)
— Stéphane Chazelas
Les implémentations RFS Tektronix / BSD ont apparemment monté des systèmes de fichiers distants sur des fichiers normaux pour éviter, findpar exemple, de traverser le point de montage. L'auteur y exclut explicitement //foo/bar(ou la connexion avec Newcastle /../foo/bar)
— Stéphane Chazelas
— Stéphane Chazelas
7

En suivant l'exemple de cette réponse . Et en lisant la page 2-15 du manuel de Bitsavers (merci @grawity ).

Données partagées
Le second principe de conception du système de fichiers distribué Domain / OS, le partage par défaut, implique un espace de noms uniforme. L'espace de noms du système de fichiers distribué apparaît aux utilisateurs comme celui d'un système de fichiers géant à temps partagé. Il s'agit d'un espace de noms hiérarchique UNIX traditionnel, sauf que les noms de chemin absolus peuvent commencer par le nom de la racine du réseau (appelée //). Il est également possible d'exprimer des noms de chemin relatifs à la racine du nœud local (le répertoire /).

Il existe également un ancien manuel de "First Printing: July, 1985". À la page 1-4:

Les doubles barres obliques (//) de la figure 1-2 représentent le niveau supérieur de l'arbre de nommage, le répertoire racine du réseau.

Nous avons donc confirmation que Domain / OS d’Apollo est utilisé //comme racine du réseau.

— Communauté
source
Je pense que le gars de grawity est un développeur Linux majeur .
— mikeserv
5

Une autre application: Blender traite un interligne //comme une référence au répertoire du projet (le répertoire dans lequel le .blendfichier est enregistré). Voici la page de manuel pertinente .

Ceci est également vrai pour les systèmes d’exploitation autres que Unix (Windows).

— wchargin
source
5

Le projet ReactOS - qui est une implémentation libre et à source ouverte du noyau NT et des API associées - a apparemment entrepris de mettre également en œuvre son propre sous-système POSIX de type Interix (bien que le sous-système OS / 2 d'origine de MS soit également mentionné dans le contexte , aucune mention n'est fournie. est constitué d’un analogue de ReactOS) .

Bien que les efforts déployés jusqu’à présent aient été modestes , fork()c’est apparemment une réalité. Voici un extrait de la page de projet du sous-système, comme indiqué dans les questions en suspens :

les chemins

Quelle est la meilleure façon d'utiliser les chemins Win32 dans les applications POSIX? des idées:

  • translate //<device>/<path> into \\.\<device>\<path> (avec un cas spécial pour les lettres de lecteur - //<letter>/<path>=> <letter>:\<path>- et le caractère d'échappement spécial //./<raw text>=> \\.\<raw text>. Les chemins UNC peuvent être spécifiés avec //unc/<path>) . //les chemins sont réservés par la norme pour le comportement spécifique à l'implémentation, et la //<letter>/syntaxe pour échapper aux chemins Win32 est largement utilisée dans les environnements de compatibilité POSIX existants

  • heuristiques pour reconnaître les chemins "nus" Win32 en tant que tels

  • Recherche insensible à la casse pour les chemins d'accès Win32 et les //chemins d'accès (la norme autorise-t-elle ce type de comportement spécifique à l'implémentation pour les //chemins d' accès?) .

Je ne suis pas certain de la pertinence de cette mesure car je ne sais pas dans quelle mesure il a été mis en œuvre, mais j’ai pensé que c’était une description intéressante du problème.

— Mikeserv
source
XENIX n’avait pas de sous - système POSIX , Windows possédait un code FAIA. XENIX était un Unix (initialement basé sur Unix V7 pour lequel Microsoft a acheté une licence à AT & T).
— Stéphane Chazelas
1
Lisez ici aussi le sous
— Stéphane Chazelas
@ StéphaneChazelas - tout à fait. Je veux presque remplacer mon lien par ce lien, mais il est un peu basé sur l'opinion, et ne fonctionne pas vraiment comme une référence ... mais ne supprimez pas le commentaire, s'il vous plaît?
— mikeserv
En tout cas, cela ne mentionne pas la //foo/barmanipulation. Je n'ai pas trouvé de preuve solide que le sous-système Windows POSIX ou Interix les ait gérés jusqu'à présent.
— Stéphane Chazelas
@ StéphaneChazelas - Je ne sais pas si c'était simplement extrêmement incohérent, ou si laisser de côté la partie optionnelle était simplement un oubli, mais la lsaclcommande MKS est spécifiée pour comprendre \\machinename\driveletter:\pathalors que sa registrycommande était spécifiée pour comprendre cette forme ou éventuellement de// toute façon. Comme le kit MKS était le prédécesseur d'Interix et que MS a livré les versions 1/2, je pense qu'Interix doit avoir accepté la syntaxe compatible pour une chose aussi fondamentale.
— mikeserv le
4

Dans les années 1980, SEL / Gould disposait d’un système d’exploitation Unix appelé UTX-32, équivalent à celui de Solaris; c'est-à-dire, chemin d'accès à distance sur l'hôte . Je ne trouve aucune documentation à ce sujet. Je ne sais donc pas s'il s'agissait d'une évolution RFS ou parallèle (ou si AT & T//host/path/net/host/pathpathhosta volé acquis de Gould).

— Scott
source
Merci. Auriez-vous des références à ce sujet ( //host/pathdans UTX-32), par hasard?
— Stéphane Chazelas
Il est possible que j'ai un document papier dans une boîte dans mon grenier, mais peu probable - (1) je ne me souviens pas d' avoir déjà beaucoup de documentation (je me souviens d'un briefing oral de cinq minutes); (2) même si je l'avais eu, je ne l'aurais peut-être pas emporté à la maison; (3) même si je l’avais emporté à la maison, je l’avais probablement jeté au cours des 30 dernières années; et (4) même si je l’ai toujours, je ne pourrai probablement pas le trouver. Oh, aussi (0) J'ai passé cinq minutes à googler (sans résultat) avant de poster ma réponse.
— Scott
4

J'ai un vague souvenir que la //host/pathnotation a été utilisée sur AT & T SysV.3 dans le cadre de son implémentation RFS Remote File Sharing . Cela a finalement été abandonné à la sortie de SysV.4 au profit du NFS, plus simple mais plus populaire, de Sun Microsystems.

Cependant, je ne trouve aucune référence concrète à la syntaxe, et la documentation que je viens de passer en revue semble indiquer que l'idée de l'utilisateur spécifiant explicitement un nom d'hôte distant se serait opposée au principe de conception d'indépendance d'emplacement.

Références 1. RFS Architectural overview

— Roaima
source
3
Founf cela à propos de RFS. Je ne trouve pas de références à //host/path. Cela semble impliquer que les systèmes de fichiers réseau doivent être montés explicitement.
— Stéphane Chazelas
Merci pour le rappel. C'est l'une des "documentations que j'ai examinées", je vais donc ajouter un lien si cela ne vous dérange pas. Je suis toujours perplexe à ce sujet; cela peut me parvenir dans les prochains jours.
— Roaima
4

Posix déclare dans la justification de la Résolution A.4.12 Pathname Les paragraphes 9 et 10:

Dans certains systèmes en réseau, la construction /../hostname/ est utilisée pour faire référence au répertoire racine d'un autre hôte, et POSIX.1 autorise ce comportement.

D'autres systèmes en réseau utilisent la construction // nom_hôte dans le même but; c'est-à-dire qu'une double barre oblique initiale est utilisée.

Cela semble confirmer que cela //signifie «racine du réseau», ou du moins que c’était l’idée lors de l’inclusion de la règle dans POSIX.

Les règles suivent pour supprimer toute signification de //au milieu d'un chemin pour un nom de chemin /commencé:

... puisque les séquences non majeures de deux <slash> caractères ou plus
sont traitées comme une seule <slash>, ...

Bien sûr, un nom de chemin //commencé peut étendre ou changer l'utilisation d' //un nom de chemin (pas au début). POSIX.1 le permet. Ce dernier confirme que les seuls //autorisés sont au début d'un chemin d'accès.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.