¿Por qué almacenar enlaces propios y principales (. Y ..) en una entrada de directorio?

11

Considere un sistema de archivos dirigido a algunos dispositivos integrados que hace poco más que almacenar archivos en una estructura de directorios jerárquica. Este sistema de archivos carece de muchas de las operaciones a las que puede estar acostumbrado en sistemas como Unix y Windows (por ejemplo, sus permisos de acceso son completamente diferentes y no están vinculados a los metadatos almacenados en los directorios). Este sistema de archivos no permite ningún tipo de enlace duro o enlace suave, por lo que cada archivo tiene un nombre único en una estructura de árbol estricta.

¿Hay algún beneficio en almacenar un enlace al directorio mismo y a su padre en la estructura de datos en disco que representa un directorio?

La mayoría de sistemas de archivos UNIX tienen .y ..entradas en el disco. Me pregunto por qué no manejan los de la capa VFS (controlador de sistema de archivos genérico). ¿Es este un artefacto histórico? ¿Existe una buena razón y, de ser así, cuál exactamente para poder determinar si es relevante para mi sistema integrado?

operating-systems filesystems

— Gilles 'SO- deja de ser malvado'
fuente

Siempre pensé que estaban allí prácticamente para que los programas pudieran acceder fácilmente al directorio actual y principal. Pregunta interesante, pero ¿pertenece aquí?

— Raphael

@Raphael Podría entender si consideras que mi pregunta es demasiado amplia (→ "no es una pregunta real"), o tal vez "no es constructiva", porque es algo abierta. Pero no estoy de acuerdo con que esté fuera de tema: se trata del diseño del sistema de archivos, ¿cómo es que no se aplica la informática? Si cree que está fuera de tema, explique su razonamiento sobre meta.

— Gilles 'SO- deja de ser malvado'

@Raphael He editado mi pregunta, espero que quede claro que mi punto de vista es el de un diseñador de SO incorporado. Gracias por tus comentarios.

— Gilles 'SO- deja de ser malvado'

2

Tener enlaces al directorio padre tiene sentido para mí. Si no los tuviera, siempre necesitaría trabajar con una lista completa de directorios. Entonces, por ejemplo, /home/svick/Documents/tendría que ser representado como { /, /home/, /home/svick/, /home/svick/Documents }. Si no hiciera eso, no podría encontrar el directorio principal (o sería muy costoso). Esto no solo es ineficiente, sino también peligroso. Si tiene dos listas de este tipo que se superponen, podrían desincronizarse fácilmente si moviera algún directorio.

Por otro lado, si tiene una referencia al directorio padre, es más eficiente y seguro.

No veo ninguna razón para tener un enlace al directorio actual. Si tiene una estructura que representa algún directorio y desea acceder a ese directorio, el uso .siempre es completamente innecesario. Por eso, esperaría que el .enlace en realidad no exista en la estructura del sistema de archivos y sea solo virtual.

— svick
fuente

2

El mismo comentario: ¿por qué hacerlo en cada sistema de archivos en lugar de en la capa VFS? La mayoría de los sistemas de archivos de Linux tienen .y ..entradas.

— Gilles 'SO- deja de ser malvado'

Como dije, creo que es más eficiente. Puede trabajar solo con el directorio actual y acceder a sus padres solo cuando lo necesite. Si no tuviera enlaces primarios, siempre necesitaría mantener todos los directorios en la ruta completa desde la raíz en la memoria. Y lo necesitaría para cada entrada que use.

— svick

1

@svick: Gilles no compara tener enlaces principales con no tener enlaces principales. Compara tenerlos en el sistema de archivos real con tenerlos simulados por una capa intermedia de código (vfs) entre el sistema de archivos real y el espacio de usuario.

— rgrig

2

Tienes menos casos especiales. En muchas situaciones, VFS puede manejar ".." como maneja cualquier otro nombre de directorio.

— rgrig
fuente

3

Si los directorios son virtuales, el programa (modo de usuario, supongo) aún puede manejarlo como cualquier otro directorio. Realmente no necesita los enlaces para presentar en el nivel de almacenamiento.

— Aryabhata

1

Sí, pero ¿por qué no manejar eso en la capa VFS? ¿Por qué habría algún almacenamiento asociado?

— Gilles 'SO- deja de ser malvado'

¿Por qué las personas implementan listas vinculadas con un centinela en lugar de ocuparse del caso de la lista vacía en las funciones de agregar / quitar?

— rgrig

@rgrig: sucede solo cuando la interfaz para la implementación de la lista vinculada considerada está escrita en un lenguaje que es excepcionalmente malo para manejar estructuras de datos inductivas (C, Java, etc.). Aquí este problema no es relevante porque la capa VFS no es directamente accesible desde el punto de vista del usuario.

— Stéphane Gimenez

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

— rgrig

2

La única razón que puedo imaginar es el siguiente escenario:

Existía una implementación original de un sistema de archivos con el mismo formato de directorio, pero las nociones de rutas de archivos y subdirectorios no se consideraron en ese momento (ver El sistema de archivos Unix PDP-7 ).
¡Entonces la gente pensó que la resolución del camino y los subdirectorios serían útiles!
Para mantener cierta compatibilidad con las implementaciones anteriores, se decidió que .y ..se almacenará en el disco como cualquier otro directorio.

Entonces, ¿tal vez nos quedemos con esos artefactos inútiles, solo por el hecho de la compatibilidad con el software de 40 años? Escenario creíble?

Nota: Además, no fue completamente estúpido agregar estas entradas a la lista del directorio, ya que de todos modos debe almacenar el número de inodo de su verdadero directorio principal (recuerde que los enlaces duros en los directorios estaban permitidos en este momento) y una referencia a su propio número de inodo podría ser un buen control de cordura.

— Stéphane Gimenez
fuente

1

No veo una razón para implementar .y ..en ningún nivel en lugar del otro. Sin embargo, si apunta a sistemas embebidos, cualquier capa que pueda guardar puede ser dinero ganado, por lo que podría tener sentido intentar implementar todo lo más bajo posible.

En cuanto a la necesidad general de .y .., ¿cómo expresaría caminos relativos sin ellos? Al menos ..es indispensable para las rutas que salen del subárbol actual. Si no necesita tales rutas (¿tal vez el árbol es una forma primitiva de codificar los privilegios de acceso?) No lo necesita ...

— Rafael
fuente