Por que armazenar links próprios e principais (. E ..) em uma entrada de diretório?

11

Considere um sistema de arquivos direcionado a alguns dispositivos incorporados que faz pouco mais do que armazenar arquivos em uma estrutura de diretórios hierárquica. Esse sistema de arquivos carece de muitas das operações com as quais você pode estar acostumado em sistemas como unix e Windows (por exemplo, suas permissões de acesso são completamente diferentes e não estão vinculadas aos metadados armazenados nos diretórios). Esse sistema de arquivos não permite nenhum tipo de vínculo físico ou virtual, portanto, todo arquivo tem um nome único em uma estrutura de árvore estrita.

Existe algum benefício em armazenar um link para o próprio diretório e seu pai na estrutura de dados em disco que representa um diretório?

Sistemas de arquivos mais UNIX têm .e ..entradas no disco. Eu me pergunto por que eles não lidam com aqueles na camada VFS (driver de sistema de arquivos genérico). Este é um artefato histórico? Existe uma boa razão e, se sim, qual exatamente, para que eu possa determinar se é relevante para o meu sistema incorporado?

operating-systems filesystems

— Gilles 'SO- parar de ser mau'
fonte

Eu sempre imaginei que eles estavam lá apenas para que os programas pudessem acessar facilmente o diretório atual e o pai. Pergunta interessante, mas pertence aqui?

— Raphael

@Raphael eu entendi se você considerou minha pergunta muito ampla (→ “não é uma pergunta real”), ou talvez “não construtiva”, porque é um tanto aberta. Mas não concordo que isso seja fora de tópico: trata-se de design de sistema de arquivos, como isso não é aplicado à ciência da computação? Se você acha que é fora do tópico, explique seu raciocínio sobre a meta.

— Gilles 'SO- stop be evil'

@ Rafael Eu editei minha pergunta, espero que fique claro que meu ponto de vista é o de um designer de SO incorporado. Obrigado por seus comentários.

— Gilles 'SO- stop be evil'

2

Ter links para o diretório pai faz sentido para mim. Se você não os tiver, sempre precisará trabalhar com uma lista inteira de diretórios. Então, por exemplo, /home/svick/Documents/teria que ser representado como { /, /home/, /home/svick/, /home/svick/Documents }. Se você não fizesse isso, não conseguiria encontrar o diretório pai (ou seria muito caro). Isso não é apenas ineficiente, mas também perigoso. Se você tiver duas listas que se sobrepõem, elas poderão ser dessincronizadas facilmente se você mover algum diretório.

Por outro lado, se você tiver uma referência ao diretório pai, é mais eficiente e seguro.

Não vejo nenhum motivo para realmente ter um link para o diretório atual. Se você possui uma estrutura que representa algum diretório e deseja acessar esse diretório, o uso .é sempre completamente desnecessário. Por causa disso, eu esperaria que o .link realmente não exista na estrutura do sistema de arquivos e seja apenas virtual.

— svick
fonte

2

A mesma observação: por que fazê-lo em cada sistema de arquivos e não na camada VFS? A maioria dos sistemas de arquivos Linux possui .e ..entradas.

— Gilles 'SO- stop be evil'

Como eu disse, acho que é mais eficiente. Você pode trabalhar apenas com o diretório atual e acessar seus pais apenas quando precisar. Se você não tiver links pai, sempre precisará manter todos os diretórios em todo o caminho longe da raiz na memória. E você precisaria disso para cada entrada que usar.

— svick

1

@svick: Gilles não compara ter links principais com não links principais. Ele compara tê-los no sistema de arquivos real com tê-los simulados por uma camada intermediária de código (vfs) entre o sistema de arquivos real e o espaço do usuário.

— Rgd #

2

Você recebe menos casos especiais. Em muitas situações, o VFS pode manipular "..", assim como qualquer outro nome de diretório.

— rgrig
fonte

3

Se os diretórios forem virtuais, o programa (modo de usuário que eu presumo) ainda poderá manipulá-lo como qualquer outro diretório. Você realmente não precisa dos links para apresentar no nível de armazenamento.

— Aryabhata

1

Sim, mas por que não lidar com isso na camada VFS? Por que haveria armazenamento associado?

— Gilles 'SO- stop be evil'

Por que as pessoas implementam listas vinculadas com um sentinela em vez de cuidar do caso de lista vazio nas funções de adição / remoção?

— Rgig # 30/12 /

@rgrig: Isso acontece apenas quando a interface para a implementação da lista vinculada considerada é escrita em uma linguagem excepcionalmente ruim no manuseio de estruturas de dados indutivas (C, Java, etc.). Aqui, esse problema não é relevante porque a camada VFS não é diretamente acessível do ponto de vista do usuário.

— Stéphane Gimenez

@ StéphaneGimenez: Este problema é relevante, porque o VFS está escrito em C.

— rgrig 13/03/12

2

A única razão pela qual posso imaginar é o seguinte cenário:

Uma implementação original de um sistema de arquivos existia com o mesmo formato de diretório, mas as noções de caminhos e subdiretórios de arquivos não foram consideradas naquele momento (consulte O sistema de arquivos PDP-7 Unix ).
Então as pessoas pensaram que a resolução do caminho e os subdiretórios seriam úteis!
Para manter uma certa compatibilidade com versões anteriores de implementações mais antigas, foi decidido que o arquivo .e ..será armazenado no disco como qualquer outro diretório.

Então, talvez tenhamos ficado com esses artefatos inúteis, apenas por uma compatibilidade retroativa com software de 40 anos? Cenário credível?

Nota: Além disso, não foi completamente estúpido adicionar essas entradas à lista de diretórios, pois você precisa armazenar o número do inode do seu diretório-pai verdadeiro em algum lugar (lembre-se de que os hardlinks nos diretórios eram permitidos no momento) e uma referência ao seu próprio número de inode pode ser uma boa verificação de sanidade.

— Stéphane Gimenez
fonte

1

Não vejo uma razão para implementar . e ..em nenhum nível e nem no outro. No entanto, se você direcionar para os sistemas incorporados, qualquer camada que possa economizar pode ser um valor agregado, por isso pode fazer sentido tentar implementar tudo o mais baixo possível.

Quanto à necessidade geral de .e .., como você expressaria caminhos relativos sem eles? Pelo menos ..é indispensável para caminhos que saem da subárvore atual. Se você não precisa desses caminhos (talvez a árvore seja uma maneira primitiva de codificar os privilégios de acesso?), Você não precisa ...

— Rafael
fonte