Acabo de empezar a leer un poco sobre el sistema de archivos de Linux. En varios lugares encontré citas como esta:
Los directorios de Unix son listas de estructuras de asociación, cada una de las cuales contiene un nombre de archivo y un número de inodo.
Así que esperaba descubrir que cada directorio contendría los nombres de los archivos que contiene, con cada archivo asignado a un inodo. Pero cuando lo hago vim directory_nameen ubuntu, me sale algo como esto:
" ============================================================================
" Netrw Directory Listing (netrw v156)
" /Users/user/workspace/folder
" Sorted by name
" Sort sequence: [\/]$,\<core\%(\.\d\+\)\=\>,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~$
" Quick Help: <F1>:help -:go up dir D:delete R:rename s:sort-by x:special
" ==============================================================================
../
./
folder1/
folder2/
file1
file2
Esperaba ver un número de inodo al lado de cada nombre de archivo, ¿por qué no es así?
Respuesta1
Esa cita trata sobre cómo (lógicamente, las estructuras reales suelen ser muy diferentes hoy en día) funcionan los sistemas de archivos Unix. Y puedes ver los números de inodo con, por ejemplo, la -ibandera para ls:
$ ls -li
total 8
532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a
532540 -rw-r--r-- 1 anthony anthony 70 Apr 25 12:07 b
Ese número de la izquierda es el inodo. Y si ejecuto ln b c(creando un enlace físico), entonces:
$ ls -li
total 12
532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a
532540 -rw-r--r-- 2 anthony anthony 70 Apr 25 12:07 b
532540 -rw-r--r-- 2 anthony anthony 70 Apr 25 12:07 c
Los permisos y el tamaño son parte del inodo, no del directorio. Es bastante fácil de ver por lo que sucede después chmod 0600 c:
$ ls -li
total 12
532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a
532540 -rw------- 2 anthony anthony 70 Apr 25 12:07 b
532540 -rw------- 2 anthony anthony 70 Apr 25 12:07 c
ambos by ccambiaron, porque comparten el mismo inodo.
Sin embargo, el kernel solo expone el sistema de archivos al espacio de usuario a través de una API bien definida (excepto para dispositivos sin formato como /dev/sda1). Proporciona acceso al espacio de usuario a un montón de llamadas al sistema para hacer cosas como crear y eliminar enlaces, cambiar permisos, leer y escribir archivos, cambiar nombres, etc. No expone las estructuras de datos subyacentes del sistema de archivos sin procesar al espacio de usuario. Esto se debe a muchas buenas razones: permite sistemas de archivos en red, significa que el kernel puede imponer permisos y mantener correctas las estructuras de datos del sistema de archivos, significa que puede usar diferentes sistemas de archivos (con diferentes estructuras de datos) sin tener que cambiar el espacio del usuario.
Básicamente, vim dires solo mostrarle una lista de directorio, más o menos como lslo hace. Se hace a través de un módulo vim llamado Netrw, como dice arriba (pruebe :help netrwen vim). En realidad, no se pueden editar las estructuras de datos del sistema de archivos subyacente.
Respuesta2
Un directorio es, semánticamente hablando, una asignación del nombre del archivo al inodo. Así es como se diseña la abstracción del árbol de directorios, correspondiente a la interfaz entre aplicaciones y sistemas de archivos. Las aplicaciones pueden designar archivos por nombre y enumerar la lista de archivos en un directorio, y cada archivo tiene un designador único que se llama "inodo".
La forma en que se implementa esta semántica depende del tipo de sistema de archivos. Depende de cada sistema de archivos cómo se codifica el directorio. En la mayoría de los sistemas de archivos Unix, un directorio es una asignación de nombres de archivos a números de inodo, y hay una tabla separada que asigna números de inodo a datos de inodo. (Los datos del inodo contienen metadatos del archivo, como permisos y marcas de tiempo, la ubicación del contenido del archivo, etc.) El mapeo puede ser una lista, una tabla hash, un árbol...
No puedes ver este mapeo con Vim. Vim no muestra el área de almacenamiento que representa el directorio. Linux, como muchos otros sistemas Unix modernos, no permite que las aplicaciones vean la representación del directorio directamente. Los directorios actúan como archivos normales en lo que respecta a su entrada de directorio y a sus metadatos, pero no en lo que respecta a su contenido. Las aplicaciones leen desde archivos normales con llamadas al sistema como open, read, write; closepara los directorios existen otras llamadas al sistema: opendir, readdir, closediry la modificación de un directorio se realiza creando, moviendo y eliminando archivos. Una aplicación como catusa open, read, closepara leer el contenido de un archivo; una aplicación como lsusa opendir, readdir, closedirpara leer el contenido de un directorio. Vim normalmente funciona como catleer el contenido de un archivo, pero si le pide que abra un directorio, funciona lse imprime los datos en un formato agradable.
Si desea ver cómo se ve un directorio en su interior, puede utilizar una herramienta como debugfsext2/ext3/ext4. ¡Asegúrate de no modificar nada! Una herramienta como debugfspasa por alto el sistema de archivos y puede destruirlo por completo. ext2/ext3/ext4 debugfses seguro porque está en modo de solo lectura a menos que permita explícitamente escribir a través de una opción de línea de comando.
# debugfs /dev/root
debugfs 1.42.12 (29-Aug-2014)
debugfs: dump / /tmp/root.bin
debugfs: quit
# od -t x1 /tmp/root.bin
Verá los nombres de las entradas del directorio entre /muchos otros caracteres, algunos no imprimibles. Para que tenga sentido, necesitaría conocer los detalles del formato del sistema de archivos.
Respuesta3
Sospecho que puedes estar leyendo una exposición muy, muy antigua sobre cómo funciona el sistema de archivos Unix. Lo que usted describe habría sido cierto a finales de la década de 1970, pero ya no es cierto en ningún sistema de archivos moderno.
En muchas plataformas modernas, existen varios sistemas de archivos de uso común y cada uno de ellos oculta sus componentes internos al espacio del usuario. Puedes descubrir cómo se ven y jugar con ellos, pero a menos que quieras especializarte en el diseño de sistemas de archivos, tal vez sea mejor confiar en que el autor del libro te dará lo suficiente como para tener una comprensión básica del diseño, sin entrar en detalles. demasiados detalles (algunos de los cuales quedarán obsoletos cuando los necesite nuevamente de todos modos).