¿Los enlaces duros cuentan como archivos normales?

21

Me preguntaba si había una manera de registrar esto, pero dado que la mayoría de los motores de búsqueda modernos no funcionan bien con frases de más de 5 palabras, necesito ayuda con esto.

Me preguntaba esto porque estoy haciendo un script bash que tiene que registrar los archivos como ciertos tipos y tomar decisiones en consecuencia. Esto técnicamente no es importante para mi proyecto, pero tenía curiosidad.

Además, si se consideran archivos normales, ¿hay alguna forma de verificar si estos archivos están vinculados sin tener que analizarlos ls -i? ¿Y hay alguna manera de verificar si algún archivo arbitrario, X, está vinculado a algún otro archivo arbitrario, Y, sin usar el find -icomando?

Mr. Minty Fresh
fuente
55
Con enlaces duros "X" no está realmente vinculado a "Y". "X" e "Y" son el mismo archivo.
jordanm
66
Todos los "archivos normales" en un directorio son enlaces duros. Algunos de estos archivos tienen más de uno.
Andrew Henle
@AndrewHenle Wow, buen punto. Ese es exactamente el tipo de cosas que estaba buscando, así que gracias.
Sr. Minty Fresh
2
@ Mr.MintyFresh En particular, no hay distinción entre el "original" y el "enlace" como lo hay para los enlaces simbólicos.
Random832

Respuestas:

38

En los sistemas de estilo Unix, la estructura de datos que representa los objetos del sistema de archivos (en otras palabras, los datos sobre un archivo), se almacena en lo que se llama un "inodo".

Un nombre de archivo es solo un enlace a este inodo, y se conoce como un "enlace duro". No hay diferencia entre el primer nombre que se le da a un archivo y cualquier enlace posterior. Entonces la respuesta es "sí": un enlace duro es un archivo normal y, de hecho, un archivo normal es un enlace duro.

El lscomando le mostrará cuántos enlaces duros hay al archivo.

Por ejemplo:

seumasmac@comp:~$ echo Hello > /tmp/hello.txt
seumasmac@comp:~$ ls -l /tmp/hello.txt 
-rw-rw-r-- 1 seumasmac seumasmac 6 Oct  4 13:05 /tmp/hello.txt

Aquí hemos creado un archivo llamado /tmp/hello.txt. En 1la salida de ls -lindica que hay 1 enlace duro a este archivo. Este enlace duro es el nombre del archivo en sí /tmp/hello.txt.

Si ahora creamos otro enlace duro a este archivo:

seumasmac@comp:~$ ln /tmp/hello.txt /tmp/helloagain.txt
seumasmac@comp:~$ ls -l /tmp/hello*
-rw-rw-r-- 2 seumasmac seumasmac 6 Oct  4 13:05 /tmp/helloagain.txt
-rw-rw-r-- 2 seumasmac seumasmac 6 Oct  4 13:05 /tmp/hello.txt

ahora puede ver que ambos nombres de archivo indican que hay 2 enlaces duros al archivo. Ninguno de estos es el nombre de archivo "apropiado", ambos son igualmente válidos. Podemos ver que ambos apuntan al mismo inodo (en este caso, 5374043):

seumasmac@comp:~$ ls -i /tmp/hello*
5374043 /tmp/helloagain.txt  5374043 /tmp/hello.txt

Existe una idea errónea de que esto es diferente para los directorios. He escuchado a personas decir que el número de enlaces devueltos por lsun directorio es el número de subdirectorios, incluidos .y ..que es incorrecto . O, al menos, si bien le dará el número correcto, ¡es correcto por los motivos equivocados!

Si creamos un directorio y hacemos un ls -ld, obtenemos:

seumasmac@comp:~$ mkdir /tmp/testdir
seumasmac@comp:~$ ls -ld /tmp/testdir
drwxrwxr-x 2 seumasmac seumasmac 4096 Oct  4 13:20 /tmp/testdir

Esto muestra que hay 2 enlaces duros a este directorio. Estos son:

/tmp/testdir
/tmp/testdir/.

Tenga en cuenta que no/tmp/testdir/.. es un enlace a este directorio, es un enlace a . Y esto le dice por qué funciona la cosa del "número de subdirectorios". Cuando creamos un nuevo subdirectorio:/tmp

seumasmac@comp:~$ mkdir /tmp/testdir/dir2
seumasmac@comp:~$ ls -ld /tmp/testdir
drwxrwxr-x 3 seumasmac seumasmac 4096 Oct  4 13:24 /tmp/testdir

ahora puede ver que hay 3 enlaces duros al /tmp/testdirdirectorio. Estos son:

/tmp/testdir
/tmp/testdir/.
/tmp/testdir/dir2/..

Por lo tanto, cada nuevo subdirectorio aumentará el número de enlaces en uno, debido a la ..entrada que contiene.

seumasmac
fuente
Entiendo cómo funcionan los metadatos, los inodos y los enlaces duros. Solo necesitaba aclarar si el archivo vinculado duro se contaba como un archivo normal. Esto solo me muestra que la respuesta es 'sí' debido a la columna dedicada a esto, que indica implícitamente que esto es nativo de todos los archivos. Lo siento mucho, pero tendré que rechazar esto :(
Mr. Minty Fresh
Eso está bien, estoy seguro de que será información útil para otra persona.
seumasmac
Edición interesante con el sistema dotglob hardlink, nunca supe que hace esto.
Sr. Minty Fresh
Aclaré los enlaces duros == párrafo de archivos regulares.
seumasmac
1
Particularmente como la oración: "Ninguno de estos es el nombre de archivo 'apropiado', ambos son igualmente válidos". Ese es un ingrediente crucial para comprender los enlaces duros. Muy bien escrito.
Comodín del
4

¿Los enlaces duros cuentan como archivos normales?

Los enlaces duros cuentan como lo que sea que estén vinculados. Puede vincular a cualquier cosa en el mismo sistema de archivos.

mkdir test
cd !$

>file
ln -s file sym
mknod pipe p

ln file file2
ln -P sym sym2
ln pipe pipe2

ls -al

# sockets, too:
cat >tsock.c <<\EOD
#include <sys/socket.h>
#include <sys/un.h>
int main(int n, char **a)
{
        struct sockaddr_un test = { AF_UNIX, "socket" };
        int testfd = socket(AF_UNIX, SOCK_SEQPACKET, 0);
        bind(testfd,(struct sockaddr *)&test,sizeof test);
}
EOD
make tsock
./tsock

ln socket socket2

ls -al

# even devices if you want:
sudo mknod mytty c 5 0
ln mytty mytty2
sudo chmod 666 mytty

ls -al
# notice permissions are on an object not on the links to it:
echo Hi, Kilroy! >mytty2  

Cada enlace rígido a cualquier cosa es equivalente, el objeto subyacente se mantiene siempre que haya algún enlace (editar: no simbólico) (incluso un descriptor de archivo abierto, por lo que estoy muy agradecido).

El sistema aplicará reglas sobre los enlaces de directorio, obtendrá un enlace con nombre a un directorio y el sistema agregará automáticamente su .enlace incrustado y los ..enlaces de cualquier subdirectorio (observe que .en el ls anterior tiene dos enlaces) pero eso es una comprobación explícita, en algunos modificados Los usuarios con sistemas privilegiados que prometen promesa prometen no hacer bucles pueden agregar nuevos enlaces ellos mismos. Al sistema de archivos no le importa, puede representar gráficos de directorio arbitrarios muy bien, pero nadie quiere lidiar con ellos.

Hay (muchos sistemas de archivos que no son Unix) que no funcionan de esta manera, incluidos algunos que llaman a lo que ofrecen como "enlaces duros" sustitutos. OS X ha acumulado un equivalente en HFS + (que no los tiene de forma nativa) si recuerdo correctamente, no sé cuán fielmente conserva la semántica aquí.

jthill
fuente
¿Qué hace ./tsockrealmente, de todos modos?
mikeserv
@mikeserv Es el programa make-a-socket de arriba, simplemente suelta un enlace de socket llamado "socket" en su directorio actual.
Jthill
ok, pero tal vez debería haber dejado en claro lo poco que sé sobre los enchufes. Creo que entiendo los enlaces lo suficientemente bien, así que solo le da al mismo socket un nuevo nombre, ¿verdad? eso no tiene ningún significado especial para los enchufes ni nada, ¿sí? Perdón por mi ignorancia.
mikeserv
1
@mikeserv Un socket es una entidad puramente en tiempo de ejecución. socket()crea un zócalo real, bind()le da un nombre específico, connect()conecta un zócalo que hizo a algún zócalo con nombre. Diferentes tipos de enchufes utilizan diferentes tipos de nombres, por ejemplo, tomas de Internet utilizan direcciones de Internet, pero todos ellos API acción ordinaria (incluyendo read()y write(), lo que me hace triste que no se puede open()una toma de sistema de archivos y tener el sistema operativo o LIBC hacer socket()y connect()para usted) . man 7 sockettiene más, todos los protocolos de red crean una página de manual inquieta.
Jthill
1
@mikeserv Mira, puedo deletrear pty y pts, y probablemente incluso ptmx en un buen día, pero eso es todo. :-) al menos el nodo 5.0 funciona en todos los lugares que puedo encontrar, es el tipo de dispositivo de control-tty. Lo obtuve con solo ls -l / dev / tty, supongo que tuve suerte allí.
Jthill