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

114

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

filenames history portability slash Stéphane Chazelas
fuente
1
Relacionado: Descripción oficial UNC (Convención de nomenclatura universal)
Stéphane Chazelas
1
@OlivierDulac, No. ls -ld ///también se mostraría ///, lssolo muestra el archivo que se le indica que muestre tal como se le dio. Estoy buscando sistemas o aplicaciones que traten // foo / var especialmente (no como una ruta en el sistema de archivos) como lo hace Cygwin.
Stéphane Chazelas
1
El estándar ( pubs.opengroup.org/onlinepubs/009695399/basedefs/… ) dice, como mencionó, "Un nombre de ruta que comienza con dos barras sucesivas puede interpretarse de una manera definida por la implementación" (más de 2 resuelve 1) . Un ejemplo encontrado en la red: 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.... no exactamente unix, aunque ^^).
Olivier Dulac
44
@DevSolar: realmente interesante (y sorprendente), pero deberíamos apegarnos solo a POSIX, ya que de POSIX todo es posible ^^
Olivier Dulac
2
@edwardtorvalds porque el primer bit es la URL: file://por igual http://y tal. En Chrome aquí en el trabajo, una ruta UNC de Windows que he abierto ahora es file:////$MACHINE/$SHARENAME/index.html(aunque por alguna razón también lo comprende file://$MACHINE/...)
agregada el

Respuestas:

90

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:

Sistemas difuntos

Aplicaciones que tratan //foo/barespecialmente para caminos

Stéphane Chazelas
fuente
3
El uso del //espacio de nombres fue propuesto por algunos desarrolladores de kernel de Linux para las instalaciones de metadatos de Reiser4, pero no creo que esta propuesta haya ganado fuerza dentro de Namesys, ni fue implementada.
Jörg W Mittag
Windows mismo implementa la API POSIX ... ¿cómo maneja eso una doble barra inclinada?
Kevin
1
Podemos agregar que en la web, los recursos que comienzan con una barra doble definen una raíz diferente que la barra simple.
Alex Gittemeier
@Kevin, sí, también lo creo (vea la pregunta), aunque creo que era un componente opcional y solo en algunas variantes de Windows y ahora descontinuado. Si tiene más detalles, agregue una respuesta.
Stéphane Chazelas
@AlexGittemeier. Sí, notarás que realmente se usa en esta respuesta ;-).
Stéphane Chazelas
16

¿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

Prem
fuente
13

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.

jlliagre
fuente
1
Corroborado por esta discusión de Usenet
Stéphane Chazelas
@ StéphaneChazelas Creo que este enlace a la discusión de Usenet es mejor. El que elija tiene Dominio / SO pero no Utek. O el siguiente mensaje (del tuyo)
del autor (trabajando en Tektronix) de la implementación de RFS de dominio público que llegó a BSD , allí se desarrollaron un DFS y un RFS.
Stéphane Chazelas
Las implementaciones de Tektronix / BSD RFS aparentemente montaron sistemas de archivos remotos en archivos normales para evitar, findpor ejemplo, atravesar el punto de montaje. El autor descarta explícitamente //foo/bar(o la conexión de Newcastle /../foo/bar) allí
Stéphane Chazelas
otro hilo de usenet que confirma DFS
Stéphane Chazelas
7

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.

Comunidad
fuente
Creo que el tipo Grawity es un gran desarrollador de Linux de Arch .
mikeserv
5

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

wchargin
fuente
5

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.

mikeserv
fuente
XENIX no tenía un subsistema POSIX , Windows tenía AFAIK. XENIX era un Unix (inicialmente basado en Unix V7 del cual Microsoft compró una licencia de AT&T).
Stéphane Chazelas
1
Buena lectura aquí también sobre el subsistema Interix / Windows POSIX
Stéphane Chazelas
@ StéphaneChazelas - bastante. Casi quiero reemplazar mi enlace con él, pero al final está un poco basado en opiniones, y realmente no funciona como referencia ... pero no elimine el comentario, ¿por favor?
mikeserv
En cualquier caso, no menciona el //foo/barmanejo. No he encontrado pruebas sólidas de que el subsistema POSIX de Windows o Interix los hayan manejado hasta ahora.
Stéphane Chazelas
@ StéphaneChazelas: no sé si fue extremadamente incosistente o si omitir la parte opcional fue solo un descuido, pero el lsaclcomando MKS debe comprender \\machinename\driveletter:\pathmientras que su registrycomando debe comprender esa forma u opcionalmente de// cualquier manera. Como el kit MKS fue el predecesor de Interix y fue lo que MS envió para las versiones 1/2, creo que Interix debe haber aceptado una sintaxis compatible para algo tan básico.
mikeserv
4

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

Scott
fuente
Gracias. ¿Tendrías alguna referencia al respecto ( //host/pathen UTX-32), por casualidad?
Stéphane Chazelas
Es posible que tenga un documento impreso en una caja en mi ático, pero es poco probable: (1) no recuerdo haber tenido mucha documentación (recuerdo una sesión informativa oral de cinco minutos); (2) incluso si lo tuviera, podría no haberlo llevado a casa; (3) incluso si lo llevé a casa, probablemente lo boté en algún momento en los últimos 30 años; y (4) incluso si todavía lo tengo, probablemente no pueda encontrarlo. Ah, también (0) Pasé cinco minutos buscándolo en Google (sin resultado) antes de publicar mi respuesta.
Scott
4

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

roaima
fuente
3
Encontré esto sobre RFS. No puedo encontrar referencias a //host/path. Parece implicar que los sistemas de archivos de red deben montarse explícitamente.
Stéphane Chazelas
Gracias por el recordatorio. Esta es una de las piezas de "documentación que he revisado", por lo que agregaré un enlace si no le importa. Todavía estoy desconcertado por esto; puede venir a mí al día siguiente más o menos.
roaima
4

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.


fuente