Sé qué son los enlaces duros, pero ¿por qué los usaría? ¿Cuál es la utilidad de un enlace duro?
Sé qué son los enlaces duros, pero ¿por qué los usaría? ¿Cuál es la utilidad de un enlace duro?
Respuestas:
La principal ventaja de los enlaces duros es que, en comparación con los enlaces blandos, no hay penalización de tamaño o velocidad. Los enlaces blandos son una capa adicional de indirección sobre el acceso normal a archivos; el núcleo tiene que desreferenciar el enlace cuando abre el archivo, y esto toma un poco de tiempo. El enlace también ocupa una pequeña cantidad de espacio en el disco para contener el texto del enlace. Estas penalizaciones no existen con enlaces duros porque están integradas en la estructura misma del sistema de archivos.
La mejor manera que conozco para ver esto es:
$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../
La -iopción lshace que te dé el número de inodo del archivo. En el sistema donde preparé el ejemplo anterior, resultó que estaba en un directorio con el número de inodo 1069765, pero el valor específico no importa. Es solo un valor único que identifica un archivo / directorio en particular.
Lo que esto dice es que cuando entramos en un subdirectorio y miramos una entrada de sistema de archivos diferente llamada .., tiene el mismo número de inodo que obtuvimos antes. Esto no sucede porque el shell está interpretando ..para usted, como sucede con MS-DOS y Windows. En los sistemas de archivos Unix ..es una entrada de directorio real; Es un enlace rígido que apunta al directorio anterior.
Los enlaces duros son los tendones que unen los directorios del sistema de archivos. Érase una vez, Unix no tenía enlaces duros. Se agregaron para convertir el sistema de archivos planos original de Unix en un sistema de archivos jerárquico.
(Para obtener más información al respecto, consulte ¿Por qué '/' tiene una entrada '...'? )
También es algo común en los sistemas Unix que varios comandos diferentes sean implementados por el mismo ejecutable. Ya no parece ser el caso en Linux, pero en los sistemas que utilicé en el pasado cp, mvy rmtodos eran el mismo ejecutable. Tiene sentido si lo piensa: cuando mueve un archivo entre volúmenes, es efectivamente una copia seguida de una eliminación, por lo que mvya tuvo que implementar las funciones de los otros dos comandos. El ejecutable puede determinar qué operación proporcionar porque pasa el nombre por el que fue llamado.
Otro ejemplo, común en Linux embebidos, es BusyBox , un único ejecutable que implementa docenas de comandos.
Debo señalar que en la mayoría de los sistemas de archivos, los usuarios no pueden hacer enlaces duros a directorios. Las entradas .y ..son gestionadas automáticamente por el código del sistema de archivos, que normalmente forma parte del núcleo. La restricción existe porque es posible causar serios problemas en el sistema de archivos si no tiene cuidado con la forma en que crea y usa los enlaces duros del directorio. Esta es una de las muchas razones por las que existen enlaces blandos; No conllevan el mismo riesgo.
Un uso de enlaces duros que es extremadamente útil es en copias de seguridad incrementales combinadas con rsync. Ahorra mucho espacio y facilita el proceso de restauración. Utilizo ese enfoque para la copia de seguridad en mis servidores.
Tómese un tiempo para leer esta explicación .
Si después de leer esa página de wikipedia tu pregunta es "¿por qué los usaría alguna vez?", Entonces no entiendes qué son los enlaces duros.
Un enlace es una entrada de directorio que apunta a bloques en el disco. En otras palabras, cada archivo en su sistema tiene al menos un enlace. Cuando usted rmarchiva la llamada real del sistema es unlink(). Elimina la entrada del directorio. Los bloques en el disco no han cambiado pero el enlace desapareció, por lo que el archivo desapareció de la lista del directorio.
Personalmente, es posible que nunca use enlaces duros, pero están en todo su sistema. Por ejemplo:
$ ls -li /bin | grep 53119771
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bunzip2
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bzcat
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bzip2
Puedes ver eso bunzip2, bzcaty bziptodos usan el mismo inodo. En esencia, es un archivo con tres nombres. Usted podría tener tres copias del archivo, pero ¿por qué? Solo usaría espacio en disco innecesariamente.
/bin, creo que esa es una de las fuentes de confusión. ¿Por qué a veces los ejecutables estarían enlazados y otras veces vinculados?
Hay muchos usos. Los uso para crear bloqueos basados en archivos. La llamada al sistema link (2) es atómica, a diferencia de la mayoría de las otras llamadas al sistema.
Otro uso es dentro de rsnapshot, donde las copias de seguridad se realizan con el tiempo mediante enlaces duros para reducir la cantidad de espacio en disco. Si un archivo no ha cambiado, entonces el archivo está vinculado a las instancias anteriores del archivo, los archivos que han cambiado se copian de nuevo.
También los uso para intercambiar archivos de configuración en servidores: rm file.cfg && ln ~/tmp/file.cfg file.cfgluego, los archivos ~ / tmp / * se pueden eliminar de forma segura.
lny en rmlugar de solo un mv?
Para agregar a las varias buenas discusiones ya presentes ...
(inode, name)pares de formato fijo significa que no hay ningún costo adicional en el sistema de archivos para tener enlaces duros (bueno, siempre que evitemos los ciclos al no permitir enlaces permanentes a los directorios (aparte de .y ..(¿Esto comienza a sentirse como un ceceo a alguien más?)))así que los conseguimos gratis.
Probablemente debería cubrir un escenario de trampa de enlaces duros. Un enlace duro será el mismo archivo con un nombre diferente y / o una ubicación diferente , siempre que exista el archivo vinculado original . Ni siquiera es correcto pensar en el archivo como "original": ambos son entradas de directorio por derecho propio, y ambos (o más) son iguales. Para archivos de larga duración, esto puede ser una bendición, pero si uno de los pares se elimina y luego se crea, incluso con el mismo nombre y contenido, los archivos se separarán.
Supongamos que ha creado un /foo/myfileenlace de enlace a /repo/myfile. Ambos son punteros a los mismos datos de archivo; cambiar uno, el otro cambia. Pero supongamos que eso /repotiene un repositorio Git. Si revisa una rama que no contiene myfile, /repo/myfilese elimina. En este momento, se /foo/myfileconvierte en una simple copia de /repo/myfile, como lo fue en el momento en que el otro par estaba desvinculado. Es fácil no darse cuenta al pasar de una rama a otra que el repertorio de archivos cambia, pero, cuando finaliza la compra de la rama original, aparece un nuevo archivo/repo/myfilees creado por Git. Si no prestó atención, se preguntaría por qué los dos archivos ahora tienen contenidos diferentes, aunque es fácil de asimilar, ya que la relación de enlace duro entre los archivos no tiene idea de sus nombres. Un enlace suave, por el contrario, sobreviviría a través de este ciclo de eliminación-creación.
Por otro lado, el software que usa enlaces duros es muy consciente de esto, y Git es un excelente ejemplo. Git clona un repositorio en el mismo sistema de archivos de forma casi gratuita, ya que utiliza enlaces duros de forma predeterminada en lugar de copiar archivos. Para Git, el enlace duro es un caso de uso perfecto, ya que sus archivos de objeto y paquete nunca cambian, por lo que un clon del repositorio nunca modificará al otro (Git sabe que no debe enlazar archivos modificables), y cualquiera de los clones puede ser eliminado sin ninguna precaución: no es necesario rastrear cuál es el "original" y realmente contiene los archivos: cualquiera de los enlaces duros es un socio igual y "contiene" el archivo completo. Los enlaces blandos simplemente no funcionarían aquí.
Otra ventaja del enlace duro es que cualquier enlace se puede mover sin interrumpir el acceso al contenido del archivo. Con enlaces suaves, mover el archivo original hace que todos los enlaces suaves cuelguen.
La conclusión es que, en muchos casos de uso, cualquier tipo de enlace funciona igual de bien, pero en uno u otro tipo es ventajoso. La eficiencia, mencionada en muchas respuestas aquí, es probablemente una preocupación muy pequeña con las máquinas y sistemas de archivos modernos, a menos que esté limpiando un sistema de archivos en un chip FLASH de un controlador incrustado. Las diferencias funcionales son más importantes y generalmente dictan las restricciones de ingeniería y la elección final:
Además, debo señalar que la llamada a la biblioteca que elimina un archivo se llama unlink()por una razón. Cada entrada de directorio es solo un enlace duro inicialmente singular a su inodo.