Muitos softwares trabalham com os pressupostos, não de fato garantidos a eles pelo POSIX.1, mas tradicionalmente o caso em sistemas UNIX e consagrados em grande parte da literatura UNIX, isso (para citar uma dessas partes do UNIX literatura):
Todo diretório contém os nomes dos arquivos dot e dot-dot (.
e..
) cujos números de inode são aqueles do diretório e seu diretório pai, respectivamente. […] O programamkfs
inicializa um sistema de arquivos para que.
e..
do diretório raiz tenham o número de inode raiz do sistema de arquivos. - Maurice J. Bach (1986). O Design do Sistema Operacional UNIX. Prentice Hall. p. 73
Por exemplo: A antiga função de biblioteca getcwd()
(em sistemas que não fornecem suporte especial para o kernel) depende disso para saber quando parar o rastreio da cadeia de ..
entradas quando compondo o nome do diretório atual. Ele pára quando atinge um diretório que é seu próprio pai ou não pode atravessar para ..
.
Portanto, o motivo pelo qual o diretório raiz tem (ou, pelo menos, programas em modo de aplicativos, pelo menos, aparece como visto através da API do sistema) uma entrada ..
é muito de coisas é baseado no pressuposto de que o diretório every tem ..
, e que ..
na raiz sendo um loop pode ser usado para detectar que um está na raiz.
POSIX.1 na verdade não garante que o diretório raiz tenha um ..
, meramente especificando que os programas devem considerar a possibilidade de um loop se houver um ..
no diretório raiz. Isso é para permitir que sistemas não UNIX também sejam compatíveis com POSIX. Existem sistemas de arquivos em que a ausência de ..
indica que um diretório é um diretório raiz. E há, como o próprio Bach discute, sistemas onde existe um diretório acima da raiz, o que POSIX.1 permite em sua discussão de nomes de caminho absolutos que começam com duas barras (semelhante à Convenção Universal de Nomenclatura usada nos sistemas de rede local da Microsoft).
O Linux (e, portanto, o Ubuntu Linux), no entanto, fornece as garantias mais estritas do paradigma do UNIX.