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

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

Um aplicativo POSIX (um aplicativo gravado na especificação POSIX para ser portátil em todos os sistemas compatíveis com POSIX) não pode assumir //foo/baro mesmo valor /foo/bar(embora eles possam assumir ///foo/baro mesmo valor /foo/bar).

Agora, quais são os sistemas POSIX (históricos e ainda mantidos) que tratam //fooespecialmente? Eu acreditava (agora estou provado errado ) que a provisão POSIX foi enviada pela Microsoft pela sua variante Unix (XENIX) e possivelmente pela camada POSIX do Windows (alguém pode confirmar isso?).

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

Em sistemas onde //foo/baré especial, para que é usado? //host/pathpara acesso a sistemas de arquivos de rede? Sistemas de arquivos virtuais?

Alguns aplicativos em execução no estilo Unix - se não a API do sistema - tratam os //foo/barcaminhos especialmente (em contextos onde eles tratam /foo/barcomo o caminho no sistema de arquivos)?

Edit , desde então, fiz uma pergunta na lista de discussão do grupo austin sobre a origem do //foo/barmanuseio nas especificações, e a discussão é uma leitura interessante (pelo menos do ponto de vista da arqueologia).

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

Sistemas atualmente mantidos ativamente:

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

Sistemas extintos

• ^@BinaryZebra Apollo Domain / OS (confirmado). Também mencionada na Descrição Oficial UNC (Convenção Universal de Nomenclatura) como a possível origem das //host/pathnotações ( consulte também a página 2-15).

  De acordo com Donn Terry , foi a HP (que adquiriu a Apollo Computers) que promoveu a inclusão dessa provisão nas especificações POSIX para Domain / OS.

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

• ^@gilles QNX 4 com o sistema de processamento distribuído FLEET, ondeestá umnó 123. (Mencionado na documentação do QNX 6. )//123/path/path
• ^@roaima AT&T SysV Release 3 (não verificado). //host/pathnosistema de compartilhamento remoto de arquivos RFS (descontinuado em SVR4).
• ^@Scott SEL / Gould UTX-32 (não verificado). Usado para//host/path.

Aplicativos que tratam //foo/barespecialmente para caminhos

• ^@Prem Perforce, onde//depot/A/B/C/Dse refere a um caminho em um depósito .
• ^@WChargin Blender . Na sua configuração, você usa um //prefixo para caminhos relativos (para a combinação associada ao bloco de dados) .

Alguns aplicativos em execução no tipo Unix - se não a API do sistema - tratam especialmente os caminhos // foo / bar?

Estou ciente do Perforce, que usa //depot/A/B/C/DCaminhos para se referir ao Depósito. O Perforce também suporta //Client/C/DCaminhos, quando o Cliente está apontando //depot/A/B/. Aqui, o sistema de arquivos local pode não ter esses caminhos.

p4 filelog //depot/A/B/C/Dmostrará o histórico desse arquivo, mesmo que não haja nenhum 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: https://www.perforce.com/perforce/r12.1/manuals/cmdref/o.fspecs.html

Várias décadas atrás, a Tektronix Utek (Unix baseado em BSD 4.2, primeiro nas CPUs National Semiconductors 32016 e depois na Motorola 68020 s) estava fornecendo algo chamado DFS (sistema de arquivos distribuído) sob o qual //foo/barse referia ao /bararquivo no fooservidor dfs. Mais tarde, foi obsoleto pelo NFS da Sun.

Infelizmente, ainda não fiz referência a isso, mas posso encontrar alguma documentação da Utek em minha adega e atualizar esta resposta.

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

Dados compartilhados
O segundo princípio de design do sistema de arquivos distribuídos do Domínio / SO, compartilhando por padrão, implica em um espaço de nome uniforme global. O espaço de nome do sistema de arquivos distribuído aparece para os usuários como o de um sistema de arquivos gigante de compartilhamento de tempo. É um espaço de nome hierárquico tradicional do UNIX, exceto que os nomes de caminho absolutos podem começar com o nome da raiz da rede (chamada //). Também é possível expressar nomes de caminho em relação à raiz do nó local (o diretório /).

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

As barras duplas (//) na Figura 1-2 representam o nível superior da árvore de nomes, o diretório raiz da rede.

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

Outra aplicação: O Blender trata um líder //como uma referência ao diretório do projeto (o diretório em que o .blendarquivo é salvo). Aqui está a página do manual relevante .

Isso também é válido para sistemas operacionais que não sejam do tipo Unix (ou seja, Windows).

O projeto ReactOS - que é uma implementação livre e de código aberto do kernel do NT e APIs relacionadas - aparentemente se comprometeu a implementar também seu próprio subsistema POSIX, semelhante ao Interix (embora o subsistema OS / 2 original da MS também seja mencionado no contexto , sem menção) é feito de um análogo do ReactOS) .

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

caminhos

Qual é a melhor maneira de usar caminhos Win32 em aplicativos POSIX? idéias:

• traduzir //<device>/<path> para \\.\<device>\<path> (com um caso especial para letras de unidade - //<letter>/<path>=> <letter>:\<path>- e o escape especial //./<raw text>=> \\.\<raw text>. os caminhos UNC podem ser especificados com //unc/<path>) . //caminhos são reservados pelo padrão para o comportamento específico da implementação, e a //<letter>/sintaxe para escapar dos caminhos Win32 é amplamente usada em ambientes de compatibilidade POSIX existentes

• heurísticas para reconhecer caminhos Win32 "vazios" como tais

• lookup case-insensitive para caminhos e Win32 //caminhos (não o padrão permitir que este tipo de comportamento específico de implementação para //caminhos?) .

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

Nos anos 80, a SEL / Gould possuía um sistema operacional Unix chamado UTX-32, equivalente ao Solaris; ou seja, acessar remotamente o caminho no host . Não consigo encontrar nenhuma documentação, portanto não sei se isso foi RFS ou evolução paralela (ou se a AT&T//host/path/net/host/pathpathhostroubou adquirida de Gould).

Tenho uma vaga memória de que a //host/pathnotação foi usada no AT&T SysV.3 como parte de sua implementação de Compartilhamento Remoto de Arquivos RFS . Isso acabou sendo abandonado na época em que o SysV.4 foi lançado em favor do NFS mais simples, porém mais popular, da Sun Microsystems.

No entanto, não consigo encontrar referências concretas à sintaxe, e a documentação que revi agora parece indicar que a idéia do usuário especificando explicitamente um nome de host remoto teria se oposto ao princípio de design da independência de local.

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

O POSIX declara no Racional para A.4.12 Parâmetros de Resolução de Nome de Caminho 9 e 10:

Em alguns sistemas em rede, a construção /../hostname/ é usada para se referir ao diretório raiz de outro host, e o POSIX.1 permite esse comportamento.

Outros sistemas em rede usam a construção // hostname para o mesmo propósito; isto é, uma barra inicial dupla é usada.

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

As regras seguem para remover qualquer significado //no meio de um caminho para um nome de /caminho iniciado:

... como seqüências não principais de dois ou mais caracteres <slash>
são tratadas como um único <slash>, ...

Obviamente, um nome de //caminho iniciado pode expandir ou alterar o uso de //dentro de um nome de caminho (não no início). O POSIX.1 permite isso. Este último confirma que os únicos //permitidos estão no início de um nome de caminho.