Auf welchen Systemen unterscheidet sich // foo / bar von / foo / bar?

114

In der gesamten POSIX-Spezifikation ist vorgesehen ( 1 , 2 , 3 ...), dass Implementierungen einen mit zwei beginnenden Pfad /speziell behandeln können.

Eine POSIX-Anwendung (eine in die POSIX-Spezifikation geschriebene Anwendung, die auf alle POSIX-kompatiblen Systeme portierbar sein soll) kann nicht davon ausgehen, dass sie //foo/barmit identisch ist /foo/bar(obwohl sie davon ausgehen können, dass sie ///foo/barmit identisch ist /foo/bar).

Was sind nun die POSIX-Systeme (historisch und immer noch gewartet), die //foospeziell behandeln ? Ich habe geglaubt (ich habe mich jetzt als falsch erwiesen ), dass die POSIX-Bereitstellung von Microsoft für die Unix-Variante (XENIX) und möglicherweise für die Windows-POSIX-Ebene (kann das jemand bestätigen?) Vorangetrieben wurde.

Es wird von Cygwin verwendet, einer POSIX-ähnlichen Ebene für Microsoft Windows. Gibt es nicht von Microsoft stammende Windows-Systeme? OpenVMS?

//foo/barWofür wird es auf Systemen mit besonderen Eigenschaften verwendet? //host/pathfür den Zugriff auf Netzwerkdateisysteme? Virtuelle Dateisysteme?

Behandeln einige Anwendungen, die unter Unix-Likes ausgeführt werden - sofern nicht die System-API - //foo/barPfade speziell (in Kontexten, in denen sie ansonsten /foo/barals Pfad im Dateisystem behandelt werden)?

Bearbeiten , ich habe seitdem eine Frage in der Mailingliste der Austin-Gruppe nach dem Ursprung der //foo/barHandhabung in der Spezifikation gestellt, und die Diskussion ist eine interessante Lektüre (zumindest aus archäologischer Sicht).

filenames history portability slash Stéphane Chazelas
quelle
1
Siehe auch: Offizielle Beschreibung UNC (Universal Naming Convention)
Stéphane Chazelas
1
@OlivierDulac, No. ls -ld ///würde auch anzeigen ///, lszeigt nur die Datei an, die angezeigt werden soll, wie sie angegeben wurde. Ich suche nach Systemen oder Anwendungen, die // foo / var speziell behandeln (nicht als Pfad im Dateisystem) wie Cygwin.
Stéphane Chazelas
1
Standard ( pubs.opengroup.org/onlinepubs/009695399/basedefs/… ) sagt, wie Sie bereits erwähnt haben: "Ein Pfadname, der mit zwei aufeinanderfolgenden Schrägstrichen beginnt, kann implementierungsdefiniert interpretiert werden" (mehr als 2 werden zu 1 / aufgelöst). . Ein Beispiel im Internet : 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.... allerdings nicht gerade unter Unix ^^).
Olivier Dulac
4
@ DevSolar: wirklich interessant (und überraschend), aber wir sollten uns nur an POSIX halten, da von POSIX aus alles möglich ist ^^
Olivier Dulac
2
@edwardtorvalds, weil das erste Bit die URL: ist file://, ähnlich wie http://und so. Auf Chrom hier bei der Arbeit ist ein Windows-UNC-Pfad, den ich jetzt geöffnet habe file:////$MACHINE/$SHARENAME/index.html(obwohl es aus irgendeinem Grund auch versteht file://$MACHINE/...)
am

Antworten:

90

Dies ist eine Zusammenstellung und ein Index der bisher gegebenen Antworten. Dieser Beitrag ist ein Community-Wiki und kann von jedem mit über 100 Reputationen bearbeitet werden, von dem niemand eine Reputation erhält. Sie können gerne Ihre eigene Antwort posten und hier einen Link hinzufügen (oder warten, bis ich es tue). Im Idealfall sollte diese Antwort nur eine Zusammenfassung sein (mit kurzen Einträgen, während einzelne andere Antworten die Details enthalten würden).

Derzeit aktiv gewartete Systeme:

Nicht mehr existierende Systeme

Anwendungen, die //foo/barspeziell für Pfade behandeln

Stéphane Chazelas
quelle
3
Die Verwendung des //Namespace wurde von einigen Linux-Kernel-Entwicklern für die Metadaten-Funktionen von Reiser4 vorgeschlagen, aber ich glaube nicht, dass dieser Vorschlag jemals innerhalb von Namesys Anklang gefunden hat, noch wurde er jemals implementiert.
Jörg W Mittag
Windows selbst implementiert die POSIX-API ... wie geht das mit einem führenden doppelten Schrägstrich um?
Kevin
1
Wir können hinzufügen, dass im Web Ressourcen, die mit einem doppelten Schrägstrich beginnen, eine andere Wurzel definieren als der einzelne Schrägstrich.
Alex Gittemeier
@ Kevin, ja ich glaube es auch (siehe die Frage), obwohl ich denke, es war eine optionale Komponente und nur auf einigen Windows-Varianten und jetzt eingestellt. Wenn Sie weitere Details haben, fügen Sie bitte eine Antwort hinzu.
Stéphane Chazelas
@AlexGittemeier. Ja, Sie werden feststellen, dass es in dieser Antwort tatsächlich verwendet wird ;-).
Stéphane Chazelas
16

Behandeln einige Anwendungen, die unter Unix-Likes ausgeführt werden - sofern nicht die System-API - // foo / bar-Pfade speziell?

Mir ist bekannt, dass Perforce //depot/A/B/C/DPfade verwendet, um auf das Depot zu verweisen. Perforce unterstützt auch //Client/C/DPfade, auf die der Client zeigt //depot/A/B/. In diesem Fall verfügt das lokale Dateisystem möglicherweise nicht über diese Pfade.

p4 filelog //depot/A/B/C/Dzeigt den Verlauf dieser Datei an, obwohl keine Datei vorhanden ist /depot/A/B/C/D.

p4 filelog C/D zeigt auch den Verlauf dieser Datei an, wenn sie über das entsprechende Verzeichnis ausgeführt wird.

Referenz: https://www.perforce.com/perforce/r12.1/manuals/cmdref/o.fspecs.html

Prem
quelle
13

Vor einigen Jahrzehnten stellte Tektronix Utek (BSD 4.2-basiertes Unix, zuerst auf 32016- CPUs von National Semiconductors, dann auf Motorola 68020 s) das so genannte DFS (Distributed File System) bereit, unter dem //foo/barauf die /barDatei auf dem fooDFS-Server verwiesen wurde. Es wurde später von Suns NFS überholt.

Leider habe ich noch keinen Hinweis darauf, aber ich könnte irgendwann eine Utek-Dokumentation in meinem Keller finden und diese Antwort aktualisieren.

jlliagre
quelle
1
Unterstützt durch diese Usenet-Diskussion
Stéphane Chazelas
@ StéphaneChazelas Ich glaube, dass dieser Link zur Usenet-Diskussion besser ist. Der von Ihnen gewählte hat Domain / OS, aber nicht Utek. Oder die nächste Nachricht (von dir)
Vom Autor (der bei Tektronix arbeitet) der gemeinfreien RFS-Implementierung, die es zu BSDs geschafft hat , wurden dort sowohl ein DFS als auch ein RFS entwickelt.
Stéphane Chazelas
Tektronix / BSD-RFS-Implementierungen haben anscheinend Remote-Dateisysteme in reguläre Dateien eingehängt , um findbeispielsweise das Überqueren des Einhängepunkts zu vermeiden . Der Autor //foo/bar/../foo/bar
Stéphane Chazelas
anderer Usenet-Thread, der DFS bestätigt
Stéphane Chazelas
7

Dem Beispiel dieser Antwort folgen . Und lies Seite 2-15 aus dem Handbuch von Bitsavers (danke @grawity ).

Freigegebene Daten
Das zweite Konstruktionsprinzip des verteilten Domain / OS-Dateisystems, das standardmäßig freigegeben wird, impliziert einen globalen einheitlichen Namensraum. Der Namensraum des verteilten Dateisystems erscheint Benutzern wie der eines riesigen Timesharing-Dateisystems. Dies ist ein traditioneller hierarchischer UNIX-Namensraum, mit der Ausnahme, dass absolute Pfadnamen mit dem Namen des Netzwerkstamms (mit dem Namen //) beginnen können. Es ist auch möglich, Pfadnamen relativ zum Stammverzeichnis des lokalen Knotens (des / -Verzeichnisses) auszudrücken.

Es gibt auch ein älteres Handbuch mit einem "First Printing: July, 1985". Auf Seite 1-4:

Die doppelten Schrägstriche (//) in Abbildung 1-2 stellen die oberste Ebene des Namensbaums dar, das Netzwerkstammverzeichnis.

Wir haben also die Bestätigung, dass Domain / OS von Apollo //als Netzwerkstamm verwendet wird.

Gemeinschaft
quelle
Ich denke der Grawity-Typ ist ein großer Linux-Entwickler .
mikeserv
5

Eine andere Anwendung: Blender behandelt einen Lead //als Verweis auf das Projektverzeichnis (das Verzeichnis, in dem die .blendDatei gespeichert ist). Hier ist die entsprechende Handbuchseite .

Dies gilt auch für nicht-Unix-ähnliche Betriebssysteme (z. B. Windows).

wchargin
quelle
5

Das ReactOS- Projekt, bei dem es sich um eine kostenlose und Open-Source-Implementierung des NT-Kernels und verwandter APIs handelt, hat sich anscheinend vorgenommen, auch ein eigenes Interix- ähnliches POSIX-Subsystem zu implementieren (obwohl das ursprüngliche OS / 2-Subsystem von MS auch im Zusammenhang erwähnt wird , keine Erwähnung) besteht aus einem ReactOS-Analogon) .

Obwohl die Anstrengungen bisher gering waren , fork()ist dies anscheinend eine Realität. Hier ist ein Auszug aus der Projektseite des Subsystems, wie unter " Offene Probleme" aufgeführt :

Pfade

Wie werden Win32-Pfade in POSIX-Anwendungen am besten verwendet? Ideen:

  • übersetzen //<device>/<pathin \\.\<device>\<path> (mit einem Sonderfall für Laufwerksbuchstaben - //<letter>/<path>=> <letter>:\<path>- und dem speziellen Escape //./<raw text>=> \\.\<raw text>. UNC-Pfade können mit angegeben werden //unc/<path>) . //Pfade sind vom Standard für implementierungsspezifisches Verhalten reserviert, und die //<letter>/Syntax zum Vermeiden von Win32-Pfaden wird in vorhandenen POSIX-Kompatibilitätsumgebungen häufig verwendet

  • Heuristiken, um "bloße" Win32-Pfade als solche zu erkennen

  • Bei der Suche nach Win32-Pfaden und //-Pfaden wird die// Groß- und Kleinschreibung nicht berücksichtigt (erlaubt der Standard diese Art von implementierungsspezifischem Verhalten für Pfade?) .

Ich bin mir nicht sicher, wie das qualifiziert ist, da ich nicht sicher bin, wie viel davon implementiert wurde, aber ich dachte, dass es eine nützliche interessante Beschreibung des Problems war.

mikeserv
quelle
XENIX hatte kein POSIX-Subsystem , Windows hatte AFAIK. XENIX war ein Unix (ursprünglich basierend auf Unix V7, von dem Microsoft eine Lizenz von AT & T gekauft hat).
Stéphane Chazelas
1
Lesen Sie auch hier mehr über das Interix / Windows POSIX-Subsystem
Stéphane Chazelas
@ StéphaneChazelas - ganz. Ich möchte fast meinen Link damit ersetzen, aber er ist am Ende ein wenig meinungsbasiert und funktioniert nicht wirklich als Referenz ... aber bitte nicht den Kommentar löschen?
mikeserv
In jedem Fall wird die //foo/barHandhabung nicht erwähnt . Ich habe bisher keine soliden Beweise dafür gefunden, dass das Windows POSIX-Subsystem oder Interix sie tatsächlich handhabten.
Stéphane Chazelas
@ StéphaneChazelas - Ich weiß nicht, ob es nur extrem inkosistent war oder ob das Weglassen des optionalen Teils nur ein Versehen war, aber der MKS- lsaclBefehl muss verstanden werden, \\machinename\driveletter:\pathwährend sein registryBefehl angegeben wurde, um diese Form zu verstehen, oder wahlweise in// beide Richtungen. Da das MKS-Kit der Vorgänger von Interix war und das war, was MS für die Versionen 1/2 geliefert hat, würde ich denken, dass Interix für solch eine grundlegende Sache kompatible Syntax akzeptiert haben muss.
mikeserv
4

In den 1980er Jahren hatte SEL / Gould ein Unix-Betriebssystem namens UTX-32, das mit Solaris vergleichbar war. dh Remote-Zugriffspfad auf dem Host . Ich kann keine Dokumentation finden, daher weiß ich nicht, ob dies RFS oder Parallel Evolution war (oder ob AT & T//host/path/net/host/pathpathhostStahl erwarb es von Gould).

Scott
quelle
Vielen Dank. Hätten Sie zufällig einen Hinweis darauf ( //host/pathin UTX-32)?
Stéphane Chazelas
Es ist möglich, dass ich ein gedrucktes Dokument in einer Box auf meinem Dachboden habe, aber es ist unwahrscheinlich - (1) Ich kann mich nicht erinnern, jemals viel Dokumentation gehabt zu haben (ich erinnere mich an eine fünfminütige mündliche Besprechung). (2) selbst wenn ich es hätte, hätte ich es vielleicht nicht mit nach Hause genommen; (3) Auch wenn ich es mit nach Hause genommen habe, habe ich es in den letzten 30 Jahren wahrscheinlich irgendwann rausgeworfen. und (4) selbst wenn ich es noch habe, werde ich es wahrscheinlich nicht finden können. Oh, auch (0) Ich habe fünf Minuten damit verbracht, es zu googeln (ohne Erfolg), bevor ich meine Antwort gepostet habe.
Scott
4

Ich habe eine vage Erinnerung, dass die //host/pathNotation auf AT & T SysV.3 als Teil der RFS Remote File Sharing- Implementierung verwendet wurde. Dies wurde schließlich eingestellt, als SysV.4 zugunsten des einfacheren, aber populäreren NFS von Sun Microsystems veröffentlicht wurde.

Ich kann jedoch keine konkreten Verweise auf die Syntax finden, und die Dokumentation, die ich gerade durchgesehen habe, scheint darauf hinzudeuten, dass die Idee, dass der Benutzer explizit einen Remote-Hostnamen angibt, dem Entwurfsprinzip der Standortunabhängigkeit widersprochen hätte.

Referenzen 1. Übersicht über die RFS-Architektur

Roaima
quelle
3
Founf this about RFS. Ich kann keine Referenzen finden //host/path. Anscheinend müssen Netzwerkdateisysteme explizit eingehängt werden.
Stéphane Chazelas
Danke für die Erinnerung. Dies ist eine der "Dokumentation, die ich überprüft habe", daher füge ich einen Link hinzu, wenn Sie nichts dagegen haben. Ich rätsele immer noch darüber; es kann am nächsten Tag zu mir kommen oder so.
Roaima
4

POSIX gibt in den Begründungen für A.4.12, Auflösung von Pfadnamen, Absätze 9 und 10 an:

In einigen vernetzten Systemen wird die Konstruktion /../hostname/ verwendet, um auf das Stammverzeichnis eines anderen Hosts zu verweisen, und POSIX.1 lässt dieses Verhalten zu.

Andere vernetzte Systeme verwenden das Konstrukt // Hostname für denselben Zweck; Dies bedeutet, dass ein doppelter Schrägstrich verwendet wird.

Dies scheint zu bestätigen, dass //dies "Netzwerkstamm" bedeutet, oder zumindest, dass dies die Idee war, als die Regel in POSIX aufgenommen wurde.

Die folgenden Regeln entfernen die Bedeutung von //in der Mitte eines Pfads für einen /gestarteten Pfadnamen:

... da nicht führende Folgen von zwei oder mehr <Schrägstrichen>
als ein einziger <Schrägstrich> behandelt werden, ...

Natürlich kann ein //gestarteter Pfadname die Verwendung //innerhalb eines Pfadnamens erweitern oder ändern (nicht am Anfang). POSIX.1 erlaubt dies. Letzteres bestätigt, dass sich die einzigen //zulässigen am Anfang eines Pfadnamens befinden.


quelle