¿Los enlaces duros cuentan como archivos normales?

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?

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.

¿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í.