Em que sistemas é // foo / bar diferente de / foo / bar?

Question

Em toda a especificação POSIX, há uma provisão ( 1 , 2 , 3 ...) para permitir que implementações tratem um caminho começando com dois / especialmente.

Um aplicativo POSIX (um aplicativo escrito para a especificação POSIX para ser portável para todos os sistemas compatíveis com POSIX) não pode assumir que //foo/bar é o mesmo que /foo/bar (embora eles possam assumir que ///foo/bar é o mesmo que /foo/bar ).

Agora, quais são os sistemas POSIX (históricos e ainda mantidos) que tratam //foo especialmente? Eu acreditei (agora eu tenho provado que ) A provisão POSIX foi empurrada pela Microsoft para a sua variante Unix (XENIX) e possivelmente a camada Windows POSIX (alguém pode confirmar isso?).

Ele é usado pelo Cygwin, que também é uma camada do tipo POSIX para o Microsoft Windows. Existem sistemas que não sejam Microsoft Windows? OpenVMS?

Em sistemas em que //foo/bar é especial, para que é usado? //host/path para acesso aos sistemas de arquivos de rede? Sistemas de arquivos virtuais?

Alguns aplicativos sendo executados em tipos de Unix - se não a API do sistema - tratam //foo/bar caminhos especialmente (em contextos onde eles tratam /foo/bar como o caminho no sistema de arquivos)? / p>

Editar , desde fiz uma pergunta sobre a lista de discussão austin-group sobre a origem do //foo/bar handling na especificação, e a discussão é uma leitura interessante (do ponto de vista da arqueologia, pelo menos).

    

Answer 1

Esta é uma compilação e um índice das respostas dadas até agora. Este post é wiki da comunidade , pode ser editado por qualquer pessoa com mais de 100 de reputação e ninguém obtém reputação disso. Sinta-se à vontade para postar sua própria resposta e adicionar um link para ela aqui (ou espere que eu faça). Idealmente, essa resposta deveria ser apenas um resumo (com pequenas entradas, enquanto outras respostas individuais teriam os detalhes).

Sistemas atualmente mantidos ativamente:

• Cygwin . Uma camada POSIX para o Microsoft Windows. Usado para caminhos UNC do Windows .
• UWIN desde 1.3 . Outra camada POSIX para o Windows. Usado pelo menos para //host/file caminhos de compartilhamento de arquivos de rede.
• ^{@OlivierDulac} IBM z / OS como mencionado no rastreador de bugs POSIX , O z / OS resolve //pathname solicitações para conjuntos de dados MVS , não para arquivos de rede. Exemplo .

Sistemas extintos

• ^@BinaryZebra < strong> Apollo Domain / OS (confirmado). Também mencionado em Descrição oficial UNC (Convenção Universal de Nomenclatura) como possível origem de //host/path notações ( veja também , página 2-15).

  De acordo com Donn Terry , foi a HP (que adquiriu a Apollo Computers) que adicionou a inclusão dessa disposição na especificação POSIX para o domínio / SO.

• ^@jillagre Tektronix Utek ( corroborada ), onde //host/path é um caminho em um sistema de arquivos distribuído .

• ^@gilles QNX 4 com o sistema de processamento distribuído FLEET, em que //123/path é um /path no nó 123. (Mencionado na documentaçà £ o do QNX 6 .
• ^@roaima AT & T SysV Release 3 (não verificado). //host/path in (descontinuado no SVR4) Sistema de Compartilhamento Remoto de Arquivos RFS .
• ^@Scott SEL / Gould UTX-32 (não verificado). Usado para //host/path .

Aplicativos que tratam //foo/bar especialmente para caminhos

• ^@Prem Perforce onde //depot/A/B/C/D refere-se a um caminho em um depot .
• ^@WChargin Liquidificador Na sua configuração você usa um prefixo // para caminhos relativos (para a mistura associado ao bloco de dados) .

Answer 2

Do some applications running on Unix-likes —if not the system's API— treat //foo/bar Paths specially?

Estou ciente do Perforce, que usa //depot/A/B/C/D Paths para se referir ao Depot. O Perforce também suporta //Client/C/D Paths, quando o cliente está apontando para //depot/A/B/ . Aqui, FileSystem local pode não ter esses caminhos.

p4 filelog //depot/A/B/C/D mostrará o histórico desse arquivo, mesmo que não haja arquivo /depot/A/B/C/D .

p4 filelog C/D também mostrará o histórico desse arquivo, se executado a partir do Diretório apropriado.

Referência: link

    

Answer 3

Várias décadas atrás, Tektronix Utek (baseado em BSD 4.2 Unix, primeiro em National Semiconductors 32016 CPUs, em seguida, Motorola 68020 s) estava fornecendo algo chamado DFS (sistema de arquivos distribuído) sob o qual //foo/bar estava se referindo ao arquivo /bar no servidor foo dfs. Mais tarde foi obsoleto pelo NFS da Sun.

Infelizmente, ainda não fiz referência para apoiar isso, mas posso eventualmente encontrar alguma documentação da Utek em meu porão e atualizar esta resposta.

    

Answer 4

Seguindo o exemplo desta resposta . E lendo a página 2-15 do manual do Bitsavers (obrigado ^@grawity ).

Shared Data
The second design principle of the Domain/OS distributed file system, sharing by default, implies a global uniform name space. The name space of the distributed file system appears to users like that of a giant timesharing file system. It is a traditional UNIX hierarchical name space, except that absolute pathnames can begin with the name of the network root (called //). It is also possible to express pathnames relative to the root of the local node (the / directory).

Há também um manual mais antigo de com o título "Primeira impressão: julho de 1985" . Na página 1-4:

The double slashes (//) in Figure 1-2 represent the top level of the naming tree, the network root directory.

Portanto, temos a confirmação de que o domínio / sistema operacional da Apollo usou // para a raiz da rede.

    

Answer 5

Outro aplicativo: O Blender trata um // como uma referência ao diretório do projeto (o diretório no qual o .blend arquivo é salvo). Esta é a página de manual relevante .

Isso também é verdadeiro para sistemas operacionais não-Unix (ou seja, Windows).

    

Answer 6

O projeto ReactOS - que é uma implementação gratuita e de código aberto do kernel do NT e APIs relacionadas - aparentemente se comprometeu a implementar também seu próprio Interix - como o subsistema POSIX (embora o subsistema OS / 2 original da MS também seja mencionado no contexto , nenhuma menção é feita a um analógico do ReactOS) .

Embora os esforços até agora tenham sido pequeno , o fork() é aparentemente uma realidade. Aqui está um trecho da página do projeto do subsistema, conforme listado em questões abertas :

paths

What's the best way to use Win32 paths in POSIX applications? ideas:

• translate //<device>/<path> into \.\<device>\<path> (with a special case for drive letters - //<letter>/<path> => <letter>:\<path> - and the special escape //./<raw text> => \.\<raw text>. UNC paths can be specified with //unc/<path>). // paths are reserved by the standard for implementation-specific behavior, and the //<letter>/ syntax to escape Win32 paths is widely used in existing POSIX compatibility environments

• heuristics to recognize "bare" Win32 paths as such

• case-insensitive lookup for Win32 paths and // paths (does the standard allow this kind of implementation-specific behavior for // paths?).

Não tenho certeza de como isso se qualifica, já que não sei ao certo quanto foi implementado, mas achei que era uma descrição útil e interessante do problema.

    

Answer 7

Na década de 1980, o SEL / Gould tinha um sistema operacional Unix chamado UTX-32 em que //host/path era equivalente a /net/host/path no Solaris; isto é, acessar remotamente o caminho path no host host . Não consigo encontrar nenhuma documentação sobre isso então eu não sei se isso foi RFS ou evolução paralela (ou se AT & T adquiriu isto de Gould).

    

Answer 8

Tenho uma vaga lembrança de que a notação //host/path foi usada no AT & T SysV.3 como parte de seu arquivo remoto RFS Compartilhando a implementação . Isso acabou sendo abandonado na época em que o SysV.4 foi lançado em favor do mais simples mas mais popular NFS da Sun Microsystems. / p>

No entanto, não consigo encontrar nenhuma referência concreta à sintaxe, e a documentação que analisei agora parece indicar que a idéia de o usuário especificar explicitamente um nome de host remoto teria se oposto ao princípio de design da independência de localização. / p>

Referências 1. Visão geral da arquitetura RFS

    

Answer 9

O POSIX declara no Racional para A.4.12 Resolução do nome do caminho < Parágrafos 9 e 10:

In some networked systems the construction /../hostname/ is used to refer to the root directory of another host, and POSIX.1 permits this behavior.

Other networked systems use the construct //hostname for the same purpose; that is, a double initial slash is used.

Isso parece para confirmar que // significa "raiz da rede", ou pelo menos que foi essa a ideia quando a regra foi incluída no POSIX.

As regras seguem para remover qualquer significado de // no meio de um caminho para um / started Pathname:

... since non-leading sequences of two or more <slash> characters
are treated as a single <slash>, ...

É claro que um // started Pathname pode expandir ou alterar o uso de // dentro de um nome de caminho (não no início). POSIX.1 permite isso. Este último confirma que o único // permitido está no início de um nome de caminho.