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

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).

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:

• Cygwin . Eine POSIX-Ebene für Microsoft Windows. Wird für Windows UNC-Pfade verwendet .
• UWIN seit 1.3. Eine weitere POSIX-Ebene für Windows. Zumindest für//host/filePfadezurDateifreigabe im Netzwerk.
• ^{@OlivierDulac} IBM z / OS Wie im POSIX-Bug-Tracker erwähnt , löst z / OS //pathnameAnforderungen in MVS-Datasets und nicht in Netzwerkdateien auf. Beispiel .

Nicht mehr existierende Systeme

• ^@BinaryZebra Apollo Domain / OS (bestätigt). Auch bei der offiziellen Beschreibung UNC (Universal Naming Convention) als möglicher Ursprung von //host/pathNotationen erwähnt ( siehe auch Seite 2-15).

  Laut Donn Terry war es HP (das Apollo Computers erworben hat), das sich für die Aufnahme dieser Bestimmung in die POSIX-Spezifikation für Domain / OS einsetzte.

• ^@jillagre Tektronix Utek ( bestätigt ), wobei//host/pathsich ein Pfad auf einem verteilten Dateisystem befindet .

• ^@gilles QNX 4 mit dem verteilten FLEET-Verarbeitungssystem, auf demsich einKnoten 123 befindet. (Erwähnt in der QNX 6-Dokumentation .)//123/path/path
• ^@roaima AT & T SysV Release 3 (nicht verifiziert). //host/pathin (eingestellt in SVR4) RFS Remote File Sharing System.
• ^@Scott SEL / Gould UTX-32 (nicht überprüft). Verwendet für//host/path.

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

• ^@Prem Perforce wo//depot/A/B/C/Dbezieht sich auf einen Pfad in einem Depot .
• ^@WChargin Blender . In seiner Konfiguration verwenden Sie ein //Präfix für relative Pfade (zu der mit dem Datenblock verknüpften Überblendung) .

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

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.

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.

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).

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.

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).

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

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.