¿Hay algún sistema de archivos para el que `ln -d` tenga éxito?


11

Desde la página de manual de ln :

-d, -F, --directory
  allow the superuser to attempt to hard link directories (note: will 
  probably fail due to system restrictions, even for the superuser)

¿Hay algún controlador de sistema de archivos que realmente permita esto, o es la única opción mount --bind <src> <dest>? ¿O el núcleo bloquea este tipo de comportamiento antes de que llegue al controlador específico del sistema de archivos?

NOTA: en realidad no estoy planeando hacer esto en ninguna máquina, solo curiosidad.

Respuestas:


6

Primero una nota: el lncomando no tiene opciones como -d, -F, --directory, este es un GNUism no portátil.

La función que está buscando es implementada por el link(1)comando.

De vuelta a su pregunta original:

En un sistema UNIX típico, la decisión, si son posibles enlaces duros en directorios, se toma en el controlador del sistema de archivos.

El controlador Solaris UFS admite enlaces duros en directorios, el controlador ZFS no.

La razón por la cual UFS en Solaris admite enlaces duros es que AT&T estaba interesado en esta función: UFS de BSD no admite directorios vinculados.

La razón por la cual ZFS no admite directorios vinculados es que a Jeff Bonwick no le gusta esa característica.

Con respecto a Linux, supongo que Linux bloquea los intentos de crear enlaces duros en los directorios en las capas superiores del kernel. La razón de esta suposición es que Linus Torvalds escribió un código para GIT que destruyó directorios cuando git clonese llamó como root en una plataforma que admite directorios vinculados.

Tenga en cuenta que un sistema de archivos que admite la creación de directorios vinculados también debe admitir la unlink(1)eliminación de directorios no vacíos como raíz.

Entonces, si suponemos que Torvalds sabe cómo funciona Linux y si Linux admitía directorios vinculados, Torvalds debería haber sabido que llamar unlink(2)a un directorio mientras es root no volverá con un error, sino que destruirá ese directorio. En otras palabras, es poco probable que Linux permita que un controlador del sistema de archivos implemente directorios vinculados.


3

La pregunta de OP menciona mount --bind. Una comprobación rápida muestra que no modifica el recuento de enlaces para el directorio que está montado. Hardlinking siempre modifica el conteo de enlaces, que puedes ver usando ls -ld.

Normalmente (la mayoría de los sistemas tipo Unix), el número de enlaces duros a un directorio será el número de directorios conectados a ese nombre, por ejemplo,

  • ".." (el directorio padre)
  • "." (el directorio en sí)
  • subdirectorios

Si usted lee el (normalmente) más informativo información página, usted puede descubrir que otros han hecho:

Oh great, one spends hours tying to find what is wrong only to
discover,
$ info ln
On all existing implementations, you cannot make a hard link to a
directory, and hard links cannot cross filesystem boundaries.  (These
restrictions are not mandated by POSIX, however.)

Therefore, kindly say everywhere you say super-user only,
instead say "few systems, super-user only".

aunque actualmente está redactado

La mayoría de los sistemas prohíben hacer un enlace duro a un directorio; en aquellos donde está permitido, solo el superusuario puede hacerlo (y con precaución, ya que crear un ciclo causará problemas a muchas otras utilidades). Los enlaces duros no pueden cruzar los límites del sistema de archivos. (Sin embargo, POSIX no exige estas restricciones).

Crear (y eliminar) enlaces duros a un directorio es una función restringida para evitar la pérdida de archivos si un directorio está desvinculado. Debido a que las operaciones de enlace / desvinculación en la interfaz del sistema operativo C son simétricas , el enlace a directorios normalmente se realiza solo en llamadas mkdir / rmdir.

Tenga en cuenta que gran parte de los coreutils de GNU se escribieron (y documentaron) hace 20-30 años, cuando algunas piezas reales del museo todavía estaban en uso. Como se señaló en cuanto a Enlace duro , originalmente no eran ninguna llamada mkdir / rmdir; Los directorios se crearon (como una operación privilegiada) utilizando enlaces duros. Todo eso desapareció cuando se agregaron las llamadas al sistema para resolver los problemas mencionados. Pero la documentación continúa haciendo referencia a estos sistemas más allá de la memoria de sus mantenedores. La opción que se cuestionó estaba en el predecesor fileutils(que se combinó con textutilsy shellutilsa mediados de la década de 1990 para formar coreutils). Algunos elementos del registro de cambios pueden ayudar a aclarar el origen de la función:

Mon Jul 23 16:57:44 1990  David J. MacKenzie  (djm at albert.ai.mit.edu)

        * cp.c (copy): Make +update operate silently, like +one-file-system.
        * ln.c: Add -F as synonym for -d, for SunOS compatibility.

Wed Feb 21 11:13:26 1990  David J. MacKenzie  (djm at albert.ai.mit.edu)

        * ln.c (error): New function.
        (main, do_link): Call error instead of fprintf and exit. 
        (main): Recognize new -d +directory option to allow superuser to
        make hard links to dirs, like the BSD ln -f option.
        (do_link): Don't allow hard links to dirs (they are hard to
        get rid of -- rmdir and unlink don't do it), unless -d was given.
        (usage): Mention -d +directory option.

Por lo tanto, puede ver, por ejemplo, que una de las antigüedades a las que se aplicaba esta característica era SunOS. La página del manual correspondiente decía esto:

OPTIONS
       -f     Force a hard link to a directory -- this option is  only   avail-
              able to the super-user.

       -s     Create a symbolic link or links.

SYSTEM V OPTIONS
       -f     Force  files to be linked without displaying permissions, asking
              questions or reporting errors.

       -F     Force a hard link to a directory -- this option is  only  avail-
              able to the super-user.

       -s     Create a symbolic link or links.

Como se señala en la documentación, esta función (y la opción correspondiente no están en POSIX (y vea la sección Justificación que explica por qué). Más bien, la función se movió a un nuevo comando (proporcionado también por GNU coreutils) llamado link. La descripción de el comando en sí es vago; debe leer la descripción de la llamada a la función para obtener cualquier uso del estándar. Sin embargo, el estándar no aclara las condiciones en las que el comando funcionaría, además de llevar adelante el descargo de responsabilidad sobre los privilegios requeridos. Para eso, debe ir a las funciones dependientes del sistema fuera del estándar:

La vinculación a un directorio está restringida al superusuario en la mayoría de las implementaciones históricas porque esta capacidad puede producir bucles en la jerarquía de archivos o dañar el sistema de archivos. Este volumen de POSIX.1-2008 continúa esa filosofía al prohibir link()y unlink()hacer esto. Otras funciones podrían hacerlo si el implementador diseñara tal extensión.

No son sistemas que utilizan enlaces duros a los directorios más allá del número normal (2 más subdirectorios).

OSX utiliza múltiples enlaces duros a directorios para archivos ordinarios . No es compatible con este uso ln(consulte la página del manual ). Según How Time Machine Works its Magic , hace esto para proporcionar las versiones utilizadas para la instalación de respaldo de Time Machine.

Otras lecturas:


3
Esto no parece responder a la pregunta en absoluto.
Michael Homer
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.