¿Casos de uso para enlaces duros? [cerrado]

¿En qué situaciones se desearía usar un enlace duro en lugar de un enlace suave? Personalmente, nunca me he encontrado con una situación en la que me gustaría usar un enlace rígido sobre un enlace blando, y el único caso de uso que he encontrado al buscar en la web es deduplicar archivos idénticos .

Además del uso de copia de seguridad mencionado en otro comentario, que creo que también incluye las instantáneas en un volumen BTRFS, un caso de uso para enlaces duros sobre enlaces blandos es una colección de archivos ordenados por etiquetas. (No es necesariamente el mejor método para crear una colección, un método basado en una base de datos es potencialmente mejor, pero para una colección simple que sea razonablemente estable, no está tan mal).

Una colección de medios donde todos los archivos se almacenan en un solo directorio plano y se clasifican en otros directorios en función de varios criterios, es decir: año, tema, artista, género, etc. Esto podría ser una colección personal de películas o un estudio comercial colectivo. trabajos. Esencialmente terminado, el archivo se guarda, no es probable que sea modificado y ordenado, posiblemente en múltiples ubicaciones por enlaces.

Tenga en cuenta que el concepto de "original" y "copia" no son aplicables a los enlaces duros: cada enlace al archivo es original, no hay "copia" en el sentido normal. Para la descripción del caso de uso, sin embargo, los términos imitan la lógica del comportamiento.

El "original" se guarda en el directorio "catálogo", y las "copias" ordenadas están vinculadas a esos archivos. Los atributos de archivo en los directorios de clasificación se pueden establecer en r / o, evitando cualquier cambio accidental en los nombres de archivo y la estructura ordenada, mientras que los atributos en el directorio de catálogo pueden ser r / w permitiendo que se modifique según sea necesario. (El caso sería archivos de música en los que algunos reproductores intentan cambiar el nombre y reorganizar los archivos en función de las etiquetas incrustadas en el archivo multimedia, de la entrada del usuario o de la recuperación de Internet). Además, dado que los atributos de los directorios de "copia" pueden ser diferentes a el directorio "original", la estructura ordenada podría estar disponible para el grupo, o el mundo, con acceso restringido, mientras que el "catálogo" principal solo es accesible para el usuario principal, Con pleno acceso. Sin embargo, los archivos mismos siempre tendrán los mismos atributos en todos los enlaces a ese inodo. (Se podría explorar ACL para mejorar eso, pero no mi área de conocimiento).

Si se cambia el nombre o se mueve el original (por ejemplo, el único directorio "catálogo" se vuelve demasiado grande para administrar) los enlaces duros permanecen válidos, los enlaces blandos se rompen. Si las "copias" se mueven y los enlaces blandos son relativos, los enlaces blandos volverán a romperse y los enlaces duros no.

Nota: parece haber inconsistencia en cómo diferentes herramientas informan el uso del disco cuando están involucrados los enlaces blandos. Con enlaces duros, sin embargo, parece consistente. Entonces, con 100 archivos en un catálogo ordenados en una colección de "etiquetas", fácilmente podría haber 500 "copias" vinculadas. (Para una colección de fotografías, diga fecha, fotógrafo y un promedio de 3 etiquetas de "sujeto"). Dolphin, por ejemplo, informaría que 100 archivos para enlaces duros y 600 archivos si se usan enlaces blandos. Curiosamente, informa el mismo uso de espacio en disco de cualquier manera, por lo que parece una gran colección de archivos pequeños para enlaces blandos, y una pequeña colección de archivos grandes para enlaces duros.

Una advertencia para este tipo de caso de uso es que en los sistemas de archivos que usan COW, modificar el "original" podría romper los enlaces duros, pero no romper los enlaces blandos. Pero, si la intención es tener la copia maestra, después de editar, guardar y ordenar, COW no entra en el escenario.

Los enlaces duros son útiles para casos en los que no desea vincular la existencia de ambos archivos. Considera esto:

touch a
ln -s a b
rm a

Ahora bes inútil. (Y estos pasos pueden suceder bastante separados, ser realizados por diferentes personas, etc.)

Mientras que con un enlace duro,

touch a
ln a b
rm a

b sigue presente y correcto.

Un solo programa puede cambiar su comportamiento dependiendo de qué nombre se inicie como:

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

Lo cual en la fuente se decide a través de algo como

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

aunque los detalles exactos variarán según el sistema operativo y el idioma involucrado.

Esto permite que (en su mayoría) el código idéntico no tenga que compilarse en dos binarios (en su mayoría) idénticos. Tenga en cuenta que las fechas de Unix son días en que el espacio en disco era muy costoso, aunque según Stevens en el capítulo 4 de APUE, los enlaces simbólicos se implementaron en BSD4.2 (1983) para reemplazar varias limitaciones de los enlaces duros. Un programa de prueba para verificar si se utiliza el nombre del enlace simbólico, ya que el nombre del programa podría verse así:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

Y probado a través de:

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$ 

Cuando mi software P2P termina de descargar un determinado archivo, el archivo se coloca en un directorio específico. Los archivos descargados casi nunca necesitan ser editados. El caso común es que hago un enlace duro en un directorio diferente donde necesito que esté el archivo.

Ventajas:

• Todavía comparto el archivo en la red P2P como debería, incluso si yo rmo mvla "copia".
• El archivo también está en la ruta donde lo necesito; La mayoría de estos lugares no se comparten.
• Puedo rmel "original" para dejar de compartir el archivo; Esta operación no afecta la "copia" en el lugar deseado.
• Mi espacio en disco se usa solo una vez.

El punto principal: si supiera de antemano qué archivo haría rmprimero, podría utilizar el enlace simbólico. Pero nunca se.

Los sistemas de archivos son una forma simple pero eficiente de organizar y clasificar archivos (esta es su razón principal de existencia). Los enlaces duros permiten un mayor grado de flexibilidad en este asunto.

Como se mencionó, no existe un concepto de original y copias cuando se trata de enlaces duros, todas las entradas de directorio (enlaces duros) son simplemente referencias a la existencia del archivo (señale su inodo) sin prioridad, por lo tanto, tampoco hay enlaces duros rotos. .

Así que aquí hay algunos de los casos de uso que atienden los enlaces duros, pero los enlaces blandos no :

1. Imagine que tiene una colección de películas o música u otros medios y desea que se apliquen diferentes criterios de clasificación, como canciones clasificadas por artista en una rama (cada artista tiene su propio subdirectorio); por género en otra rama (cada una en un subdirectorio diferente), etc. Aún así no desea duplicar los archivos ni decidir dónde colocar el "original" para que tenga la libertad de reclasificar sin tener que " administrar "y volver a vincular archivos cuando se mueve para evitar enlaces rotos.

2. Otra razón es evitar el desperdicio de espacio de almacenamiento que se requeriría para tener múltiples copias del mismo archivo y, sin embargo, permitir que la chrootllamada al sistema se beneficie de un subconjunto de archivos en la raíz del sistema de archivos "maestro" (los enlaces simbólicos nunca podrían hacer referencia a archivos externos) la chrootcaja de arena, incluso si tienen rutas relativas).

3. Otra razón muy importante pero raramente mencionada para que existan enlaces duros son los ..subdirectorios. Los ..directorios en realidad son (en la mayoría de las implementaciones de Unix fs) enlaces duros al directorio padre, sin enlaces duros esto tiene que implementarse de una manera completamente diferente, mientras que la existencia de enlaces duros hace que esto sea muy fácil de implementar.

Un ejemplo muy común en el mundo real que necesita enlaces duros:

git clone --reference <repository>

Esto se clona desde un repositorio local de Git con casi cero copias. En lugar de copiar los archivos de objetos (archivos inmutables utilizados por Git para su "base de datos"), simplemente los vincula.

Cualquier repositorio puede eliminar un objeto, pero el inodo permanece válido para el resto de los repositorios. Y si un objeto se elimina de todos los repositorios, se elimina del disco. Los enlaces duros son una solución hermosamente robusta y rápida. Muy común en servidores CI.

Existe una versión no dura-link: git clone --shared <repository>. Esto, sin embargo, es voluble y tiene muchas más advertencias ya que todos están trabajando en el mismo directorio.

Recientemente tuve un caso de uso para un procedimiento de actualización algo seguro para sistemas basados ​​en U-Boot donde uImagehay un enlace suave que apunta a la imagen para arrancar, la idea era que un corte de energía no planteara problemas, sin importar en qué punto del proceso ocurre (suponiendo que el sistema de archivos se reproduce):

ln image.bin backup_image.bin
ln -sf backup_image.bin uImage

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

Sin enlaces duros no sería tan simple.

/editar:

Gracias a los comentarios ahora sé que sería mejor hacerlo:

ln image.bin backup_image.bin
ln -sf backup_image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage

// replace image.bin

ln -sf image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
rm backup_image.bin

(El rmestá aquí para poder escapar mejor de un estado extraño, por ejemplo, si uImagees algo inesperado que haría mvfallar [pero no necesariamente la ln -sfsolución anterior ]).

Un uso que he tenido para los enlaces duros es al descargar o descomprimir un archivo roto. El programa que descarga o descomprime (como descomprimir o descomprimir) a menudo eliminará automáticamente el archivo incompleto cuando encuentre un error, y generalmente no hay opción para conservarlo. Si quiero mantener el archivo, puedo hacer un enlace duro a él.

BackupPC es un sistema de respaldo que utiliza enlaces duros en los servidores para proporcionar deduplicación a nivel de archivo.

Los archivos se almacenan primero en un árbol de directorios "pool" en función de su hash md5. Cualquier copia de seguridad que haga uso de ese archivo crea un enlace rígido al archivo del grupo. A medida que las copias de seguridad caducan / se eliminan, sus enlaces duros se eliminan del sistema de archivos.

Los enlaces duros son superiores a los enlaces blandos aquí porque proporcionan un conteo automático de referencias. Un trabajo cron elimina periódicamente los archivos en el directorio del grupo que no tienen más de un enlace.

Este método tiene algunas desventajas (principalmente, que es difícil usar herramientas basadas en el sistema de archivos para replicar el almacén de copias de seguridad), pero se ha demostrado que es bastante robusto en la práctica.

Otro caso de uso: el servidor de aplicaciones web tomcat java trata los nombres de archivo como metadatos. Se debe nombrar un archivo "war" de Java en función de su ruta en el servidor web.

por ejemplo: foo.war es el código de Java que sirve a la URL/foo

Desafortunadamente, resuelve los enlaces simbólicos antes de tomar esta decisión.

Por lo tanto, supongamos que desea implementar una compilación de la aplicación y asígnele un nombre de archivo descriptivo (por ejemplo, con un número o fecha de lanzamiento). No puede hacer un enlace simbólico al archivo con el nombre "real": debe crear un enlace duro.

foo.warenlazado a foo-20170129.warno funciona

foo.warvinculado a las foo-20170129.warobras.

No me gusta este comportamiento de Tomcat, pero los enlaces duros me dan una forma de evitarlo.