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

114

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

filenames history portability slash Stéphane Chazelas
fonte
11
Relacionado: Descrição oficial UNC (Convenção Universal de Nomenclatura)
Stéphane Chazelas
11
@OlivierDulac, No. ls -ld ///também será exibido ///, lsapenas exibe o arquivo que está sendo solicitado a exibir como foi fornecido. Estou procurando por sistemas ou aplicativos que tratem // foo / var especialmente (não como um caminho no sistema de arquivos) como o Cygwin.
Stéphane Chazelas
11
O padrão ( pubs.opengroup.org/onlinepubs/009695399/basedefs/… ) diz, como você mencionou, "Um nome de caminho que começa com duas barras sucessivas pode ser interpretado de uma maneira definida pela implementação" (mais de 2 resolve para 1 /) . Um exemplo encontrado na rede: 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.... não exatamente unix, no entanto ^^).
Olivier Dulac
4
@DevSolar: realmente interresting (e surpreendente), mas devemos ficar com POSIX somente, como fora de POSIX qualquer coisa é possível ^^
Olivier Dulac
2
@edwardtorvalds porque o primeiro bit é a URL:, da file://mesma forma http://e assim por diante . Em cromo aqui no trabalho um caminho janelas UNC que eu tenho aberto agora é file:////$MACHINE/$SHARENAME/index.html(embora por algum motivo ele também entende file://$MACHINE/...)
admalledd

Respostas:

90

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:

Sistemas extintos

Aplicativos que tratam //foo/barespecialmente para caminhos

Stéphane Chazelas
fonte
3
O uso do //namespace foi proposto por alguns desenvolvedores de kernel Linux para os recursos de metadados do Reiser4, mas acho que essa proposta nunca ganhou força no Namesys, nem foi implementada.
Jörg W Mittag
O próprio Windows implementa a API POSIX ... como isso lida com uma barra dupla líder?
Kevin
11
Podemos acrescentar que, na Web, os recursos que começam com uma barra dupla definem uma raiz diferente da barra única.
Alex Gittemeier
@ Kevin, sim, eu também acredito (veja a pergunta), apesar de achar que era um componente opcional e apenas em algumas variantes do Windows e agora descontinuado. Se você tiver mais detalhes, adicione uma resposta.
Stéphane Chazelas
@AlexGittemeier. Sim, você notará que é realmente usado nesta resposta ;-).
Stéphane Chazelas
16

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

Prem
fonte
13

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.

jlliagre
fonte
11
Corroborada por esta discussão da usenet
Stéphane Chazelas
@ StéphaneChazelas Acredito que este link para a discussão da Usenet seja melhor. O que você escolher possui Domínio / SO, mas não Utek. Ou a próxima mensagem (da sua)
do autor (trabalhando na Tektronix) da implementação de RFS de domínio público que chegou aos BSDs , havia um DFS e um RFS desenvolvidos lá.
Stéphane Chazelas
As implementações do Tektronix / BSD RFS aparentemente montaram sistemas de arquivos remotos em arquivos regulares para evitar, findpor exemplo, atravessar o ponto de montagem. O autor descarta explicitamente //foo/bar(ou as conexões de Newcastle /../foo/bar) lá
Stéphane Chazelas
outro thread da usenet que confirma o DFS
Stéphane Chazelas
7

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.

Comunidade
fonte
Eu acho que o cara do grawity é um dos principais desenvolvedores do Linux .
mikeserv
5

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

wchargin
fonte
5

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.

mikeserv
fonte
O XENIX não possui um subsistema POSIX , o Windows possui o AFAIK. O XENIX era um Unix (inicialmente baseado no Unix V7, do qual a Microsoft comprou uma licença da AT&T).
Stéphane Chazelas
11
Nice Leia aqui bem sobre interix subsistema / Windows POSIX
Stéphane Chazelas
@ StéphaneChazelas - bastante. Eu quase quero substituir meu link por ele, mas é um pouco baseado em opiniões no final e realmente não funciona como referência ... mas não exclua o comentário, por favor?
mikeserv
De qualquer forma, não menciona //foo/barmanuseio. Não encontrei fortes evidências de que o subsistema Windows POSIX ou o Interix realmente os tenha manipulado até agora.
Stéphane Chazelas 26/01
@ StéphaneChazelas - Não sei se era apenas extremamente incosistente ou se deixar de fora a parte opcional era apenas uma supervisão, mas o lsaclcomando MKS deve entender \\machinename\driveletter:\pathenquanto seu registrycomando deve entender essa forma ou opcionalmente de// qualquer maneira. Como o kit MKS foi o antecessor do Interix e foi o que a Microsoft enviou para as versões 1/2, eu acho que o Interix deve ter aceitado uma sintaxe compatível para algo tão básico.
precisa saber é o seguinte
4

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

Scott
fonte
Obrigado. Você teria alguma referência a isso ( //host/pathno UTX-32), por acaso?
Stéphane Chazelas
É possível que eu tenha um documento impresso em uma caixa no meu sótão, mas improvável: (1) não me lembro de ter tido muita documentação (lembro-me de um briefing oral de cinco minutos); (2) mesmo que eu o tivesse, talvez não o tivesse levado para casa; (3) mesmo que eu tenha levado para casa, provavelmente joguei fora algum tempo nos últimos 30 anos; e (4) mesmo que ainda o possua, provavelmente não o encontrarei. Ah, também (0) passei cinco minutos pesquisando no Google (sem sucesso) antes de postar minha resposta.
Scott
4

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

roaima
fonte
3
Encontre isso sobre o RFS. Não consigo encontrar referências a //host/path. Parece implicar que os sistemas de arquivos de rede precisam ser montados explicitamente.
Stéphane Chazelas
Obrigado pela lembrança. Esta é uma das partes da "documentação que revi", por isso adicionarei um link, se você não se importa. Eu ainda estou intrigado com isso; pode vir até mim no dia seguinte.
roaima
4

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.


fonte