Do padrão POSIX ( 4.13 Pathname Resolution , onde as entradas .e ..são referidas como "ponto" e "ponto-ponto" respectivamente):
O ponto de nome de arquivo especial deve se referir ao diretório especificado por seu predecessor. O nome de arquivo especial ponto-ponto deve se referir ao diretório pai de seu diretório predecessor. Como um caso especial, no diretório raiz, ponto-ponto pode se referir ao próprio diretório raiz.
O que o nome do arquivo ponto-ponto refere-se ao diretório raiz é definido pela implementação. Na versão 7 refere-se ao próprio diretório raiz; este é o comportamento mencionado em POSIX.1-2017. 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 //hostnamepara o mesmo propósito; ou seja, uma inicial dupla <slash>é usada. [...]
Então, resumindo, o padrão POSIX diz que todo diretório deve ter entradas .e .., e permite que a ..entrada do diretório in faça / referência ao /próprio diretório (observe a palavra "pode" no primeiro texto citado), mas também permite uma implementação para que se refira a outra coisa.
As implementações mais comuns de sistemas de arquivos /..resolvem o /.
Kusalananda já lhe disse que este é o comportamento especificado pelo padrão POSIX. No entanto, a história do UNIX começou para valer no início dos anos 1970. O POSIX remonta apenas à segunda metade da década de 1980, uma década e meia depois. Na prática, o POSIX apenas especificava o que já estava sendo feito pelas implementações.
Em vez disso, o UNIX deu suporte muito cedo à montagem de sistemas de arquivos em diferentes dispositivos em sua única hierarquia de diretórios unificada. Cada sistema de arquivos, na verdade, tem seu próprio diretório raiz; o sistema de arquivos montado em /não é particularmente especial de forma alguma. (Seu conteúdo pode ser, mas o próprio sistema de arquivos não é.)
As chamadas de sistema sysmounte sysumountparecem ter sido introduzidas no UNIX V1, em 1970-1971 (a V1 é datada de 1971-11, de acordo com a Árvore Unix da Unix Heritage Society ). Eles são definidos em u1.s (números de chamada do sistema 21 e 22, respectivamente) e implementados em u7.s . (PDP7 UNIX, datado de 1970-01, não parece ter nenhum ancestral óbvio daqueles ).
Você provavelmente vê para onde isso está indo: quando qualquer sistema de arquivos pode ser montado em qualquer local na hierarquia, para evitar casos especiais, cada diretório, incluindo o diretório raiz de cada sistema de arquivos, deve conter uma entrada apontando para seu próprio diretório pai. No disco, o local lógico para apontar a entrada do diretório pai do diretório-raiz de um sistema de arquivos é o diretório-raiz do sistema de arquivos, porque não há mais nada "acima" do diretório-raiz do sistema de arquivos. O conceito de ter algo "acima" do diretório raiz só entra em jogo quando esse sistema de arquivos é montado em algum local diferente da raiz da hierarquia.
Durante a montagem, é possível reescrever o ponteiro "diretório pai" na cópia de memória do diretório raiz para apontar para o diretório pai do diretório do ponto de montagem. Se não houver nenhum diretório pai do diretório do ponto de montagem (em outras palavras, o sistema de arquivos está sendo montado como /), então deixe esse pedaço de dados sozinho (porque provavelmente não há nenhum outro lugar sensato para apontá-lo de qualquer maneira) ou trate-o separadamente mais tarde (como provavelmente seria o caso dos /../hostname/pathe //hostname/pathcasos mencionados na resposta de Kusalananda).
O comportamento resultante é que em qualquer diretório diferente de /, independentemente de ser o diretório raiz de um sistema de arquivos específico ou um subdiretório (em qualquer nível de aninhamento), ..aponta para o diretório pai desse diretório; e em /, ..aponta de volta para /. O primeiro é o que parece natural ( ..sempre funciona da mesma maneira, movendo você um passo em direção ao diretório raiz), enquanto o último, embora um pouco idiossincrático, pelo menos obviamente não quebra nada (há pouco dano em não ser capaz de mover mais para o diretório raiz do que para o próprio diretório raiz). Por exemplo, você pode criar um número arbitrário de ../e saber que pelo menos eles não causarão um erro porque..em algum momento não existe.
Existe um diretório acima /, /em si. O diretório pai do diretório raiz é ele mesmo. cd ..ou cd ../..dentro do diretório raiz deve deixá-lo no mesmo lugar, não causar um erro.
Observe que nenhuma .ou ..pode existir como entradas de diretório reais em alguns sistemas de arquivos, elas podem ser simplesmente emuladas pela camada do sistema de arquivos virtual do SO.
Um caminho como /../hostnamedeveria permitir que você acesse a raiz de outro host em alguns sistemas pré-vfs e pré-nfs como MUNIX (usando o "Newcastle Connection" ), mas não conheço nenhum sistema desse tipo ainda em uso, e o código-fonte está longe de ser encontrado.
As informações disponíveis são altamente contraditórias, mas parece que a maneira mais comum de implantar esse sistema era recompilar todos os programas para que todas as chamadas de uso de caminho open(2)pudessem ser redirecionadas no espaço do usuário (não havia bibliotecas compartilhadas naquela época).
Provavelmente havia centenas desses hacks ( o scratchbox é um mais recente que eu tive o desprazer de ter que usar), então não está claro por que eles sentiram a necessidade de acomodá-lo no padrão POSIX.
Além de todas as outras razões mencionadas aqui, é a simplicidade do design , algo pelo qual o UNIX é conhecido. Todos os diretórios contêm ..; casos especiais são sempre perigos de tropeçar (para segurança ou robustez) aparecendo no escuro. Então, em vez de forçar os programadores a lidar com um caso raro em muitos lugares, todos os diretórios são projetados para ter entradas .e ..são tratados de maneira uniforme, e /não é necessário considerar o que acontece.
A
..entrada no diretório raiz é um caso especial.Do padrão POSIX ( 4.13 Pathname Resolution , onde as entradas
.e..são referidas como "ponto" e "ponto-ponto" respectivamente):A lógica tem isso a acrescentar ( A.4.13 Resolução do nome do caminho )
Então, resumindo, o padrão POSIX diz que todo diretório deve ter entradas
.e.., e permite que a..entrada do diretório in faça/referência ao/próprio diretório (observe a palavra "pode" no primeiro texto citado), mas também permite uma implementação para que se refira a outra coisa.As implementações mais comuns de sistemas de arquivos
/..resolvem o/.Kusalananda já lhe disse que este é o comportamento especificado pelo padrão POSIX. No entanto, a história do UNIX começou para valer no início dos anos 1970. O POSIX remonta apenas à segunda metade da década de 1980, uma década e meia depois. Na prática, o POSIX apenas especificava o que já estava sendo feito pelas implementações.
Em vez disso, o UNIX deu suporte muito cedo à montagem de sistemas de arquivos em diferentes dispositivos em sua única hierarquia de diretórios unificada. Cada sistema de arquivos, na verdade, tem seu próprio diretório raiz; o sistema de arquivos montado em
/não é particularmente especial de forma alguma. (Seu conteúdo pode ser, mas o próprio sistema de arquivos não é.)As chamadas de sistema
sysmountesysumountparecem ter sido introduzidas no UNIX V1, em 1970-1971 (a V1 é datada de 1971-11, de acordo com a Árvore Unix da Unix Heritage Society ). Eles são definidos em u1.s (números de chamada do sistema 21 e 22, respectivamente) e implementados em u7.s . (PDP7 UNIX, datado de 1970-01, não parece ter nenhum ancestral óbvio daqueles ).Você provavelmente vê para onde isso está indo: quando qualquer sistema de arquivos pode ser montado em qualquer local na hierarquia, para evitar casos especiais, cada diretório, incluindo o diretório raiz de cada sistema de arquivos, deve conter uma entrada apontando para seu próprio diretório pai. No disco, o local lógico para apontar a entrada do diretório pai do diretório-raiz de um sistema de arquivos é o diretório-raiz do sistema de arquivos, porque não há mais nada "acima" do diretório-raiz do sistema de arquivos. O conceito de ter algo "acima" do diretório raiz só entra em jogo quando esse sistema de arquivos é montado em algum local diferente da raiz da hierarquia.
Durante a montagem, é possível reescrever o ponteiro "diretório pai" na cópia de memória do diretório raiz para apontar para o diretório pai do diretório do ponto de montagem. Se não houver nenhum diretório pai do diretório do ponto de montagem (em outras palavras, o sistema de arquivos está sendo montado como
/), então deixe esse pedaço de dados sozinho (porque provavelmente não há nenhum outro lugar sensato para apontá-lo de qualquer maneira) ou trate-o separadamente mais tarde (como provavelmente seria o caso dos/../hostname/pathe//hostname/pathcasos mencionados na resposta de Kusalananda).O comportamento resultante é que em qualquer diretório diferente de
/, independentemente de ser o diretório raiz de um sistema de arquivos específico ou um subdiretório (em qualquer nível de aninhamento),..aponta para o diretório pai desse diretório; e em/,..aponta de volta para/. O primeiro é o que parece natural (..sempre funciona da mesma maneira, movendo você um passo em direção ao diretório raiz), enquanto o último, embora um pouco idiossincrático, pelo menos obviamente não quebra nada (há pouco dano em não ser capaz de mover mais para o diretório raiz do que para o próprio diretório raiz). Por exemplo, você pode criar um número arbitrário de../e saber que pelo menos eles não causarão um erro porque..em algum momento não existe.Existe um diretório acima
/,/em si. O diretório pai do diretório raiz é ele mesmo.cd ..oucd ../..dentro do diretório raiz deve deixá-lo no mesmo lugar, não causar um erro.Observe que nenhuma
.ou..pode existir como entradas de diretório reais em alguns sistemas de arquivos, elas podem ser simplesmente emuladas pela camada do sistema de arquivos virtual do SO.Um caminho como
/../hostnamedeveria permitir que você acesse a raiz de outro host em alguns sistemas pré-vfs e pré-nfs como MUNIX (usando o "Newcastle Connection" ), mas não conheço nenhum sistema desse tipo ainda em uso, e o código-fonte está longe de ser encontrado.As informações disponíveis são altamente contraditórias, mas parece que a maneira mais comum de implantar esse sistema era recompilar todos os programas para que todas as chamadas de uso de caminho
open(2)pudessem ser redirecionadas no espaço do usuário (não havia bibliotecas compartilhadas naquela época).Provavelmente havia centenas desses hacks ( o scratchbox é um mais recente que eu tive o desprazer de ter que usar), então não está claro por que eles sentiram a necessidade de acomodá-lo no padrão POSIX.
Além de todas as outras razões mencionadas aqui, é a simplicidade do design , algo pelo qual o UNIX é conhecido. Todos os diretórios contêm
..; casos especiais são sempre perigos de tropeçar (para segurança ou robustez) aparecendo no escuro. Então, em vez de forçar os programadores a lidar com um caso raro em muitos lugares, todos os diretórios são projetados para ter entradas.e..são tratados de maneira uniforme, e/não é necessário considerar o que acontece.