¿En qué sistemas es // foo / bar diferente de / foo / bar?

A lo largo de la especificación POSIX, hay disposiciones ( 1 , 2 , 3 ...) para permitir que las implementaciones traten una ruta que comienza con dos /especialmente.

Una aplicación POSIX (una aplicación escrita en la especificación POSIX para ser portátil a todos los sistemas compatibles con POSIX) no puede asumir que //foo/bares lo mismo que /foo/bar(aunque sí puede suponer que ///foo/bares lo mismo /foo/bar).

¿Cuáles son esos sistemas POSIX (históricos y aún mantenidos) que tratan //fooespecialmente? Creí (ahora se ha demostrado que estoy equivocado ) que la provisión POSIX fue impulsada por Microsoft para su variante Unix (XENIX) y posiblemente para la capa POSIX de Windows (¿alguien puede confirmar eso?).

Lo usa Cygwin, que también es una capa similar a POSIX para Microsoft Windows. ¿Hay algún sistema que no sea Microsoft Windows? OpenVMS?

En sistemas donde //foo/bares especial, ¿para qué se utiliza? //host/pathpara acceso a sistemas de archivos de red? Sistemas de archivos virtuales?

¿Algunas aplicaciones que se ejecutan en Me gusta de Unix, si no es en la API del sistema, tratan las //foo/barrutas especialmente (en contextos en los que de otro modo se tratan /foo/barcomo la ruta en el sistema de archivos)?

Editar , desde entonces hice una pregunta en la lista de correo del grupo Austin sobre el origen del //foo/barmanejo en la especificación, y la discusión es una lectura interesante (al menos desde el punto de vista de la arqueología).

Esta es una compilación e índice de las respuestas dadas hasta ahora. Esta publicación es wiki de la comunidad , puede ser editada por cualquier persona con más de 100 reputación y nadie obtiene reputación de ella. Siéntase libre de publicar su propia respuesta y agregar un enlace aquí (o espere a que lo haga). Idealmente, esta respuesta debería ser solo un resumen (con entradas cortas, mientras que otras respuestas individuales tendrían los detalles).

Sistemas actualmente mantenidos activamente:

• Cygwin . Una capa POSIX para Microsoft Windows. Utilizado para rutas UNC de Windows .
• UWIN desde 1.3. Otra capa POSIX para Windows. Se utiliza al menos para//host/filerutas de intercambio de archivos de red.
• ^{@OlivierDulac} IBM z / OS como se menciona en el rastreador de errores POSIX , z / OS resuelve //pathnamesolicitudes a conjuntos de datos MVS , no a archivos de red. Ejemplo .

Sistemas difuntos

• ^@BinaryZebra Apollo Domain / OS (confirmado). También se menciona en la Descripción oficial UNC (Convención de nomenclatura universal) como el posible origen de las //host/pathanotaciones ( ver también , página 2-15).

  Según Donn Terry , fue HP (que adquirió las computadoras Apollo) la que impulsó la inclusión de esa disposición en la especificación POSIX para el dominio / sistema operativo.

• ^@jillagre Tektronix Utek ( corroborado ), donde//host/pathhay una ruta en un sistema de archivos distribuido .

• ^@gilles QNX 4 con el sistema de procesamiento distribuido FLEET, donde seencuentraen el nodo 123. (Mencionado en la documentación de QNX 6 ).//123/path/path
• ^@roaima AT&T SysV Release 3 (sin verificar). //host/pathen (descontinuado en SVR4) RFS Remote File Sharing system.
• ^@Scott SEL / Gould UTX-32 (sin verificar). Se utiliza para//host/path.

Aplicaciones que tratan //foo/barespecialmente para caminos

• ^@Prem Perforce donde se//depot/A/B/C/Drefiere a una ruta en un depósito .
• ^@WChargin Blender . En su configuración , utiliza un //prefijo para rutas relativas (a la combinación asociada con el bloque de datos) .

¿Algunas aplicaciones que se ejecutan en Me gusta de Unix, si no es la API del sistema, tratan las rutas // foo / bar especialmente?

Soy consciente de Perforce que utiliza //depot/A/B/C/Drutas para referirse al Depósito. Perforce también admite //Client/C/Drutas, cuando el cliente señala //depot/A/B/. Aquí, el FileSystem local puede no tener estas Rutas.

p4 filelog //depot/A/B/C/Dmostrará el historial de ese archivo, aunque no haya ningún archivo /depot/A/B/C/D.

p4 filelog C/D también mostrará el historial de ese archivo, si se ejecuta desde el Directorio apropiado.

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

Hace varias décadas, Tektronix Utek (Unix basado en BSD 4.2, primero en CPU National Semiconductors 32016 y luego Motorola 68020 s) estaba proporcionando algo llamado DFS (sistema de archivos distribuido) bajo el cual //foo/barse refería al /bararchivo en el fooservidor dfs. Más tarde fue obsoleto por NFS de Sun.

Desafortunadamente, aún no he hecho referencia para respaldar eso, pero eventualmente podría encontrar documentación de Utek en mi bodega y actualizar esta respuesta.

Siguiendo el ejemplo de esta respuesta . Y leyendo la página 2-15 del manual de Bitsavers (gracias ^@grawity ).

Datos compartidos
El segundo principio de diseño del sistema de archivos distribuido Dominio / SO, compartir de manera predeterminada, implica un espacio de nombre global uniforme. El espacio de nombres del sistema de archivos distribuido parece a los usuarios como el de un sistema de archivos de tiempo compartido gigante. Es un espacio de nombre jerárquico tradicional de UNIX, excepto que los nombres de ruta absolutos pueden comenzar con el nombre de la raíz de la red (llamada //). También es posible expresar nombres de ruta relativos a la raíz del nodo local (el directorio /).

También hay un manual más antiguo de "Primera impresión: julio de 1985". En la página 1-4:

Las barras diagonales dobles (//) en la Figura 1-2 representan el nivel superior del árbol de nombres, el directorio raíz de la red.

Entonces, tenemos confirmación de que el dominio / sistema operativo de Apollo se usó //para la raíz de la red.

Otra aplicación: Blender trata una guía //como una referencia al directorio del proyecto (el directorio en el .blendque se guarda el archivo). Aquí está la página del manual relevante .

Esto también es cierto para los sistemas operativos que no son similares a Unix (es decir, Windows).

El proyecto ReactOS , que es una implementación gratuita y de código abierto del kernel NT y API relacionadas, aparentemente se ha comprometido a implementar también su propio subsistema POSIX similar a Interix (aunque el subsistema OS / 2 original de MS también se menciona en contexto , sin mencionar está hecho de un análogo ReactOS) .

Aunque los esfuerzos hasta ahora han sido pequeños , fork()aparentemente es una realidad. Aquí hay un extracto de la página del proyecto del subsistema, como se detalla en los números abiertos :

rutas

¿Cuál es la mejor manera de usar rutas de Win32 en aplicaciones POSIX? ideas:

• traducir //<device>/<path> a \\.\<device>\<path> (con un caso especial para letras de unidad - //<letter>/<path>=> <letter>:\<path>- y el escape especial //./<raw text>=> \\.\<raw text>. Las rutas UNC se pueden especificar con //unc/<path>) . //las rutas están reservadas por el estándar para el comportamiento específico de la implementación, y la //<letter>/sintaxis para escapar de las rutas Win32 se usa ampliamente en entornos de compatibilidad POSIX existentes

• heurística para reconocer las rutas "desnudas" de Win32 como tales

• búsqueda sin distinción entre mayúsculas y minúsculas para rutas y //rutas de Win32 (¿permite el estándar este tipo de comportamiento específico de implementación para //rutas?) .

No estoy seguro de cómo eso califica, ya que no estoy seguro de cuánto se ha implementado, pero pensé que era una descripción útil e interesante del problema.

En la década de 1980, SEL / Gould tenía un sistema operativo Unix llamado UTX-32 en el que era equivalente a Solaris; es decir, ruta de acceso remoto en el host . No puedo encontrar ninguna documentación al respecto, así que no sé si fue RFS o evolución paralela (o si AT&T//host/path/net/host/pathpathhostrobó lo adquirí de Gould).

Tengo un vago recuerdo de que la //host/pathnotación se usó en AT&T SysV.3 como parte de su implementación de RFS Remote File Sharing . Finalmente, esto se abandonó cuando SysV.4 se lanzó a favor del NFS más simple pero más popular de Sun Microsystems.

Sin embargo, no puedo encontrar ninguna referencia concreta a la sintaxis, y la documentación que he revisado ahora parece indicar que la idea del usuario que especifica explícitamente un nombre de host remoto se habría opuesto al principio de diseño de la independencia de la ubicación.

Referencias 1. Descripción arquitectónica de RFS

De POSIX establece en el Fundamento de la Resolución del nombre de ruta A.4.12 Los párrafos 9 y 10:

En algunos sistemas en red, la construcción /../hostname/ se usa para referirse al directorio raíz de otro host, y POSIX.1 permite este comportamiento.

Otros sistemas en red utilizan la construcción // nombre de host con el mismo propósito; es decir, se usa una doble barra inicial.

Esto parece confirmar que //significa "raíz de red", o al menos esa fue la idea cuando la regla se incluyó en POSIX.

Siguen las reglas para eliminar cualquier significado //en el medio de una ruta para un nombre de ruta /iniciado:

... ya que las secuencias no iniciales de dos o más caracteres de <barra inclinada>
se tratan como una sola <barra inclinada>, ...

Por supuesto, un nombre de //ruta iniciado puede expandir o cambiar el uso de //dentro de un nombre de ruta (no al principio). POSIX.1 permite esto. Esto último confirma que los únicos //permitidos están al comienzo de un Nombre de ruta.