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