Primero una nota:el ln el comando no tiene opciones como -d , -F , --directory , este es un GNUismo no portable.
La función que está buscando está implementada por link(1) comando.
Volviendo a su pregunta original:
En un sistema UNIX típico, la decisión de si son posibles los enlaces físicos en los directorios se toma en el controlador del sistema de archivos.
El controlador UFS de Solaris admite enlaces físicos en directorios, el controlador ZFS no.
La razón por la que UFS en Solaris admite enlaces fijos es que AT&T estaba interesado en esta función:UFS de BSD no admite directorios con enlaces fijos.
La razón por la que 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 directorios en las capas superiores del kernel. El motivo de esta suposición es que Linus Torvalds escribió código para GIT que destruyó directorios cuando git clone fue llamado como root en una plataforma que admite directorios vinculados.
Tenga en cuenta que un sistema de archivos que admita la creación de directorios vinculados también debe ser compatible con unlink(1) para eliminar directorios no vacíos como root.
Entonces, si asumimos que Torvalds sabe cómo funciona Linux y si Linux admitía directorios vinculados, Torvalds debería haber sabido que llamar a unlink(2) en un directorio mientras es root, no regresará con un error sino que destruirá ese directorio. EN otras palabras, es poco probable que Linux permita que un controlador de sistema de archivos implemente directorios vinculados.
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. Enlace permanente siempre modifica el recuento de enlaces, que puede ver usando ls -ld .
Normalmente (la mayoría de los sistemas similares a Unix), la cantidad de enlaces fijos a un directorio será la cantidad de directorios conectados a ese nombre, por ejemplo,
".."(el directorio principal)"."(el directorio en sí)- subdirectorios
Si lee la (normalmente) más informativa info página, puede descubrir como otros lo 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 fijo a un directorio; en aquellas donde está permitido, sólo 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, estas restricciones no son obligatorias por POSIX).
La creación (y eliminación) de enlaces fijos a un directorio es una característica restringida para evitar la pérdida de archivos si se desvincula un directorio. Porque las operaciones de vinculación/desvinculación en la interfaz del sistema operativo C son simétricas , la vinculación a directorios normalmente se realiza solo en llamadas mkdir/rmdir.
Tenga en cuenta que gran parte de GNU coreutils se escribió (y documentó) hace 20 o 30 años, cuando algunas piezas de museo reales todavía estaban en uso. Como se señaló en Acerca de Hard Link, originalmente había eran sin llamadas mkdir/rmdir; los directorios se crearon (como una operación privilegiada) usando 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 cuestionada estaba en el predecesor fileutils (que se combinó con textutils y shellutils a 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.
Entonces, puede ver, por ejemplo, que una de las antigüedades para las que se aplicó esta función fue 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 indica en la documentación, esta característica (y la opción correspondiente no están en POSIX (y consulte la Racionalidad sección que explica por qué). Más bien, la característica se movió a un nuevo comando (proporcionado también por GNU coreutils) llamado link . La descripción del comando en sí es vaga; debe leer la descripción de la llamada de función para obtener cualquier uso del estándar. Sin embargo, la norma no aclara las condiciones en las que trabajaría el comando, además de llevar adelante la renuncia 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 con esa filosofía al prohibir link() y unlink() de hacer esto. Otras funciones podrían hacerlo si el implementador diseñara dicha extensión.
Hay son sistemas que usan enlaces duros a directorios más allá del número normal (2 más subdirectorios).
OSX usa múltiples enlaces duros a directorios para archivos ordinarios . No es compatible con esto usando ln (ver página del manual). Según How Time Machine Works its Magic, hace esto para proporcionar las versiones utilizadas para la función de copia de seguridad de Time Machine.
Lectura adicional:
- ¿Por qué OS X Time Machine crea enlaces de directorio?
- ¿Cuál es el comando de Unix para crear un enlace fijo a un directorio en OS X?