Su quali sistemi è // foo / bar diverso da / foo / bar?

In tutta la specifica POSIX, ci sono disposizioni ( 1 , 2 , 3 ...) per consentire alle implementazioni di trattare un percorso che inizia con due /appositamente.

Un'applicazione POSIX (un'applicazione scritta in base alle specifiche POSIX per essere trasportabile su tutti i sistemi POSIX compatibili) non può presumere che //foo/barsia la stessa /foo/bar(sebbene possano presumere che ///foo/barsia la stessa /foo/bar).

Ora quali sono quei sistemi POSIX (storici e ancora mantenuti) che trattano in modo //foospeciale? Ho creduto (ora mi è stato smentito ) che la fornitura POSIX è stata spinta da Microsoft per la sua variante Unix (XENIX) e forse per il livello POSIX di Windows (qualcuno può confermarlo?).

Viene utilizzato da Cygwin che è anche un livello simile a POSIX per Microsoft Windows. Esistono sistemi non Microsoft Windows? OpenVMS?

Sui sistemi in cui //foo/barè speciale, a cosa serve? //host/pathper l'accesso ai file system di rete? File system virtuali?

Alcune applicazioni in esecuzione su Unix-like —se non l'API di sistema — trattano i //foo/barpercorsi in modo speciale (in contesti in cui altrimenti trattano /foo/barcome il percorso sul filesystem)?

Modifica , da allora ho posto una domanda sulla mailing list del gruppo austin sull'origine del //foo/bartrattamento nelle specifiche e la discussione è una lettura interessante (almeno dal punto di vista dell'archeologia).

Questa è una raccolta e un indice delle risposte fornite finora. Questo post è wiki della comunità , può essere modificato da chiunque abbia più di 100 reputazione e nessuno ne ottiene la reputazione. Sentiti libero di pubblicare la tua risposta e aggiungere un link qui (o attendere che io lo faccia). Idealmente, questa risposta dovrebbe essere solo un sommario (con voci brevi mentre le altre risposte individuali avrebbero i dettagli).

Sistemi attualmente gestiti attivamente:

• Cygwin . Un livello POSIX per Microsoft Windows. Utilizzato per i percorsi UNC di Windows .
• UWIN dal 1.3. Un altro livello POSIX per Windows. Utilizzato almeno per//host/filei percorsi di condivisione dei file di rete.
• ^{@OlivierDulac} IBM z / OS come menzionato nel tracker di bug POSIX , z / OS risolve le //pathnamerichieste nei set di dati MVS , non nei file di rete. Esempio .

Sistemi defunti

• ^@BinaryZebra Apollo Domain / OS (confermato). Anche menzionato nella Descrizione ufficiale UNC (Universal Naming Convention) come possibile origine delle //host/pathnotazioni ( vedere anche , pagina 2-15).

  Secondo Donn Terry , è stato HP (che ha acquisito Apollo Computers) a spingere per l'inclusione di tale disposizione nelle specifiche POSIX per dominio / sistema operativo.

• ^@jillagre Tektronix Utek ( corroborato ), dove si//host/pathtrova un percorso su un file system distribuito .

• ^@gilles QNX 4 con il sistema di elaborazione distribuito FLEET, doveè presente unnodo 123. (Citato nella documentazione di QNX 6 ).//123/path/path
• ^@roaima AT&T SysV Release 3 (non verificato). //host/pathnelsistema di condivisione file remoto RFS (fuori produzione in SVR4).
• ^@Scott SEL / Gould UTX-32 (non verificato). Usato per//host/path.

Applicazioni che trattano //foo/barappositamente per i percorsi

• ^@Prem Perforce dove si//depot/A/B/C/Driferisce a un percorso in un deposito .
• ^@WChargin Blender . Nella sua configurazione si utilizza un //prefisso per i percorsi relativi (alla fusione associata al blocco dati) .

Alcune applicazioni in esecuzione su Mi piace di Unix, se non l'API di sistema, trattano in modo specifico i percorsi // foo / bar?

Sono a conoscenza di Perforce che utilizza //depot/A/B/C/DPercorsi per fare riferimento al deposito. Perforce supporta anche //Client/C/DPercorsi, quando il Cliente punta //depot/A/B/. Qui, il FileSystem locale potrebbe non avere questi percorsi.

p4 filelog //depot/A/B/C/Dmostrerà la cronologia di quel file, anche se non ci sono file /depot/A/B/C/D.

p4 filelog C/D mostrerà anche la cronologia di quel file, se eseguito dalla directory appropriata.

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

Diversi decenni fa, Tektronix Utek (Unix basato su BSD 4.2, prima su CPU National Semiconductors 32016 e poi Motorola 68020 s) stava fornendo qualcosa chiamato DFS (file system distribuito) in base al quale //foo/barsi riferiva al /barfile sul fooserver dfs. In seguito fu obsoleto da Sun NFS.

Sfortunatamente, non ho ancora fatto riferimento a questo, ma alla fine potrei trovare della documentazione di Utek nella mia cantina e aggiornare questa risposta.

Seguendo l'esempio di questa risposta . E leggendo la pagina 2-15 dal manuale di Bitsavers (grazie a ^@grawity ).

Dati condivisi
Il secondo principio di progettazione del file system distribuito Dominio / OS, la condivisione per impostazione predefinita, implica uno spazio dei nomi uniforme globale. Lo spazio dei nomi del file system distribuito appare agli utenti come quello di un file system di multiproprietà gigante. È uno spazio dei nomi gerarchico UNIX tradizionale, tranne per il fatto che i nomi di percorso assoluti possono iniziare con il nome della radice di rete (chiamato //). È anche possibile esprimere percorsi relativi alla radice del nodo locale (la directory /).

C'è anche un manuale più vecchio di "Prima stampa: luglio 1985". A pagina 1-4:

Le doppie barre (//) nella Figura 1-2 rappresentano il livello superiore dell'albero dei nomi, la directory radice della rete.

Quindi, abbiamo la conferma che il dominio / sistema operativo di Apollo utilizzato //per il root di rete.

Un'altra applicazione: Blender tratta un lead //come riferimento alla directory del progetto (la directory in cui .blendviene salvato il file). Ecco la pagina di manuale pertinente .

Questo vale anche per i sistemi operativi non simili a Unix (ovvero Windows).

Il progetto ReactOS - che è un'implementazione gratuita e open source del kernel NT e delle API correlate - si è apparentemente impegnato a implementare anche il proprio sottosistema POSIX simile a Interix (sebbene anche il sottosistema OS / 2 originale di MS sia menzionato nel contesto , nessuna menzione è composto da un analogo ReactOS) .

Sebbene gli sforzi finora siano stati piccoli , fork()sembra essere una realtà. Ecco un estratto dalla pagina del progetto del sottosistema, come elencato in numeri aperti :

percorsi

Qual è il modo migliore per utilizzare i percorsi Win32 nelle applicazioni POSIX? idee:

• translate //<device>/<path> in \\.\<device>\<path> (con un caso speciale per le lettere di unità - //<letter>/<path>=> <letter>:\<path>- e lo speciale escape //./<raw text>=> \\.\<raw text>. I percorsi UNC possono essere specificati con //unc/<path>) . //i percorsi sono riservati dallo standard per comportamenti specifici dell'implementazione e la //<letter>/sintassi per sfuggire ai percorsi Win32 è ampiamente utilizzata negli ambienti di compatibilità POSIX esistenti

• euristica per riconoscere i percorsi "nudi" di Win32 come tali

• ricerca senza distinzione tra maiuscole e minuscole per percorsi e //percorsi Win32 (lo standard consente questo tipo di comportamento specifico per l'implementazione per i //percorsi?) .

Non sono sicuro di come si qualifichi poiché non sono sicuro di quanto sia stato implementato, ma ho pensato che fosse una descrizione utilmente interessante del problema.

Negli anni '80, SEL / Gould aveva un sistema operativo Unix chiamato UTX-32 in cui era equivalente a Solaris; cioè, accedere in remoto al percorso sull'host . Non riesco a trovare alcuna documentazione al riguardo, quindi non so se si trattasse di RFS o evoluzione parallela (o se AT&T//host/path/net/host/pathpathhostha rubato acquisito da Gould).

Ho una vaga memoria che la //host/pathnotazione è stata utilizzata su AT&T SysV.3 come parte della sua implementazione di RFS Remote File Sharing . Questo alla fine è stato abbandonato nel periodo in cui SysV.4 è stato rilasciato a favore della NFS più semplice ma più popolare di Sun Microsystems.

Tuttavia, non riesco a trovare riferimenti concreti alla sintassi e la documentazione che ho esaminato in questo momento sembra indicare che l'idea dell'utente che specifica esplicitamente un nome host remoto si sarebbe opposta al principio di design dell'indipendenza della posizione.

Riferimenti 1. Panoramica di RFS Architectural

POSIX afferma nel Razionale per A.4.12 Pathname risoluzione Paragrafi 9 e 10:

In alcuni sistemi in rete la costruzione /../hostname/ viene utilizzata per fare riferimento alla directory principale di un altro host e POSIX.1 consente questo comportamento.

Altri sistemi in rete usano il costrutto // nomehost per lo stesso scopo; cioè, viene utilizzata una doppia barra iniziale.

Ciò sembra confermare che //significa "root di rete", o almeno quello era l'idea quando la regola era inclusa in POSIX.

Le regole seguono per rimuovere qualsiasi significato //nel mezzo di un percorso per un /Nome percorso avviato:

... poiché le sequenze non iniziali di due o più caratteri <slash>
vengono trattate come un singolo <slash>, ...

Naturalmente, un //Pathname avviato può espandere o modificare l'uso di //Inside Pathname (non all'inizio). POSIX.1 lo consente. Quest'ultimo conferma che gli unici //ammessi sono all'inizio di un Pathname.