¿Por qué los enlaces duros parecen ocupar el mismo espacio que los originales?


14

Gracias a algunas buenas preguntas y respuestas por aquí y esta página , ahora entiendo los enlaces. Veo que los enlaces duros refieren el mismo inodo con un nombre diferente, y las copias son diferentes "nodos, con diferentes nombres. Además, los enlaces blandos tienen el nombre y la ruta del archivo original como inodo, por lo que si el archivo se mueve, el enlace se rompe.

Entonces, probé lo que aprendí con algún archivo ("saluton_mondo.cpp" a continuación), hice un enlace duro y suave y una copia.

jmcf125@VMUbuntu:~$ ls -lh soft hard copy s*.cpp
-rw-rw-r-- 1 jmcf125 jmcf125 205 Aŭg 27 16:10 copy
-rw-rw-r-- 2 jmcf125 jmcf125 205 Aŭg 25 13:34 hard
-rw-rw-r-- 2 jmcf125 jmcf125 205 Aŭg 25 13:34 saluton_mondo.cpp
lrwxrwxrwx 1 jmcf125 jmcf125  17 Aŭg 27 16:09 soft -> saluton_mondo.cpp

Me pareció incómodo que el enlace duro, sin embargo, tenga el mismo tamaño que el original y, lógicamente, la copia. Si el enlace duro y el original comparten el mismo inodo, que tiene los datos, y solo difieren por el nombre del archivo, ¿no debería el enlace duro tomar solo el espacio de su nombre, en lugar de 205 bytes? ¿O es ese el tamaño del archivo original que ls -lhregresa? Pero entonces, ¿cómo puedo saber qué espacio ocupa el nombre de archivo? Aquí dice que los enlaces duros no tienen tamaño. ¿Su nombre de archivo se mantiene junto al nombre de archivo original? ¿Dónde se almacena el nombre de archivo de los enlaces duros?

Respuestas:


16

Un archivo es un inodo con metadatos entre los cuales hay una lista de punteros a dónde encontrar los datos.

Para poder acceder a un archivo, debe vincularlo a un directorio (piense en los directorios como directorios telefónicos, no carpetas), es decir, agregue una o más entradas a uno o más directorios para asociar un nombre con ese archivo.

Todos esos enlaces, esos nombres de archivo apuntan al mismo archivo. No hay uno que sea original y otros que sean enlaces. Todos son puntos de acceso al mismo archivo (mismo inodo) en el árbol de directorios. Cuando obtiene el tamaño del archivo ( lstatllamada al sistema), está recuperando información (los metadatos mencionados anteriormente) almacenados en el inodo, no importa qué nombre de archivo, qué enlace esté utilizando para referirse a ese archivo .

Por el contrario, los enlaces simbólicos son otro archivo (otro inodo) cuyo contenido es una ruta al archivo de destino. Al igual que cualquier otro archivo, esos enlaces simbólicos deben estar vinculados a un directorio (debe tener un nombre) para que pueda acceder a ellos. También puede tener varios enlaces a enlaces simbólicos, o en otras palabras, los enlaces simbólicos pueden recibir varios nombres (en uno o más directorios).

$ touch a
$ ln a b
$ ln -s a c
$ ln c d
$ ls -li [a-d]
10486707 -rw-r--r-- 2 stephane stephane 0 Aug 27 17:05 a
10486707 -rw-r--r-- 2 stephane stephane 0 Aug 27 17:05 b
10502404 lrwxrwxrwx 2 stephane stephane 1 Aug 27 17:05 c -> a
10502404 lrwxrwxrwx 2 stephane stephane 1 Aug 27 17:05 d -> a

Sobre el número de archivo 10486707 hay un archivo normal. Dos entradas en el directorio actual (una con nombre ay otra con nombre b) se vinculan a él. Debido a que el recuento de enlaces es 2, sabemos que no hay otro nombre de ese archivo en el directorio actual ni en ningún otro directorio. El número de archivo 10502404 es otro archivo, esta vez de tipo enlace simbólico vinculado dos veces al directorio actual. Su contenido (objetivo) es la ruta relativa "a".

Tenga en cuenta que si 10502404 estaba vinculado a otro directorio que el actual, normalmente apuntaría a un archivo diferente dependiendo de cómo se accedió.

$ mkdir 1 2
$ echo foo > 1/a
$ echo bar > 2/a
$ ln -s a 1/b
$ ln 1/b 2/b
$ ls -lia 1 2
1:
total 92
10608644 drwxr-xr-x   2 stephane stephane  4096 Aug 27 17:26 ./
10485761 drwxrwxr-x 443 stephane stephane 81920 Aug 27 17:26 ../
10504186 -rw-r--r--   1 stephane stephane     4 Aug 27 17:24 a
10539259 lrwxrwxrwx   2 stephane stephane     1 Aug 27 17:26 b -> a

2:
total 92
10608674 drwxr-xr-x   2 stephane stephane  4096 Aug 27 17:26 ./
10485761 drwxrwxr-x 443 stephane stephane 81920 Aug 27 17:26 ../
10539044 -rw-r--r--   1 stephane stephane     4 Aug 27 17:24 a
10539259 lrwxrwxrwx   2 stephane stephane     1 Aug 27 17:26 b -> a
$ cat 1/b
foo
$ cat 2/b
bar

Los archivos no tienen nombres asociados a ellos que no sean en los directorios que los vinculan. El espacio ocupado por sus nombres son las entradas en esos directorios, se tiene en cuenta en el tamaño del archivo / uso del disco de los directorios.

Notarás que la llamada al sistema para eliminar un archivo es unlink. Es decir, no elimina archivos, los desvincula de los directorios a los que se hace referencia. Una vez desvinculados del último directorio que tenía una entrada en un archivo determinado, ese archivo se destruye (siempre que no haya ningún proceso) abrió).


Ahh ... Ahora ya veo. Entonces, un archivo llamado "hola" y su copia exacta llamada "ajhĝjdmjefsjmksgskgjkmŝŭna" toman exactamente la misma cantidad de espacio; porque sus nombres no cuentan para esa lstatllamada al sistema que obtiene su tamaño.
JMCF125

@ JMCF125, sí, el tamaño tomado por sus nombres es la entrada en los directorios correspondientes, se contabiliza en el tamaño de archivo de los directorios.
Stéphane Chazelas

Gracias. ¿Puedes incluir eso en tu respuesta? Espera, aclararé mi pregunta primero.
JMCF125

5

El enlace duro es, esencialmente, el archivo original. Entonces, el tamaño que ve reportado es el tamaño del archivo al que se está vinculando. Son los enlaces blandos que solo ocupan el espacio de sus nombres (más o menos).

En lo que respecta al sistema de archivos, el enlace duro y el original son lo mismo, apuntan al mismo inodo, por lo que se informa el mismo tamaño.


Pero el nombre del enlace duro debe ocupar espacio, ¿correcto?
JMCF125

Vea la respuesta de @ stephan a continuación, él lo explica mejor.
terdon

2
@ JMCF125 Sí, pero ese espacio está dentro del directorio. Si crea suficientes archivos, notará que aumenta el tamaño del directorio. El tamaño de un archivo no incluye sus metadatos, como su nombre.
Gilles 'SO- deja de ser malvado'

@Gilles, gracias, pero @Stephane ya ha actualizado su respuesta con esa información. Además, ahora lo pienso mejor, el nombre de /debe ser almacenado en sí mismo, como si lo hicieras cd ..en /tu interior /.
JMCF125
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.