Prima una nota:il ln Il comando non ha opzioni come -d , -F , --directory , questo è uno GNUismo non portabile.
La funzionalità che stai cercando è implementata dal link(1) comando.
Torniamo alla tua domanda iniziale:
Su un tipico sistema UNIX la decisione, se sono possibili hard link sulle directory, viene presa nel driver del filesystem.
Il driver Solaris UFS supporta gli hard link nelle directory, il driver ZFS no.
Il motivo per cui UFS su Solaris supporta gli hard link è che AT&T era interessata a questa funzione:UFS da BSD non supporta le directory con hard link.
Il motivo per cui ZFS non supporta le directory con collegamenti fisici è che a Jeff Bonwick non piace questa caratteristica.
Per quanto riguarda Linux, immagino che Linux blocchi i tentativi di creare hard link nelle directory nei livelli superiori del kernel. La ragione di questa supposizione è che Linus Torvalds ha scritto codice per GIT che distruggeva le directory quando git clone è stato chiamato come root su una piattaforma che supporta le directory hard link.
Nota che un filesystem che supporta la creazione di directory hard link deve anche supportare unlink(1) per rimuovere le directory non vuote come root.
Quindi, se assumiamo che Torvalds sappia come funziona Linux e se Linux supportava le directory con collegamenti fisici, Torvalds avrebbe dovuto sapere che chiamare unlink(2) su una directory pur essendo root, non restituirà un errore ma distruggerà quella directory. In altre parole, è improbabile che Linux permetta a un driver del file system di implementare directory hard link.
La domanda di OP menziona mount --bind . Un rapido controllo mostra che non modifica il conteggio dei collegamenti per la directory montata. Hardlinking sempre modifica il conteggio dei link, che puoi vedere usando ls -ld .
Normalmente (la maggior parte dei sistemi simili a Unix), il numero di collegamenti fisici a una directory sarà il numero di directory collegate a quel nome, ad esempio,
".."(la directory principale)"."(la directory stessa)- sottodirectory
Se leggi le informazioni (di solito) più informative pagina, potresti scoprire come altri hanno fatto:
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".
anche se attualmente è formulato
La maggior parte dei sistemi vieta la creazione di un collegamento reale a una directory; su quelli dove è consentito lo può fare solo il superutente (e con cautela, visto che creare un ciclo causerà problemi a molte altre utenze). Gli hard link non possono attraversare i confini del file system. (Tuttavia, queste restrizioni non sono imposte da POSIX.)
La creazione (e la rimozione) di collegamenti fisici a una directory è una funzionalità limitata per evitare la perdita di file se una directory è scollegata. Perché le operazioni di collegamento/scollegamento nell'interfaccia del sistema operativo C sono simmetriche , il collegamento alle directory viene normalmente eseguito solo nelle chiamate mkdir/rmdir.
Tieni presente che gran parte dei coreutils GNU è stata scritta (e documentata) 20-30 anni fa, quando alcuni veri pezzi da museo erano ancora in uso. Come notato in Riguardo a Hard Link, in origine ce n'erano nessuna chiamata mkdir/rmdir; le directory sono state create (come operazione privilegiata) utilizzando collegamenti reali. Tutto ciò è andato via quando sono state aggiunte le chiamate di sistema per risolvere i problemi menzionati. Ma la documentazione continua a fare riferimento a questi sistemi oltre la memoria dei loro manutentori. L'opzione messa in discussione era nel predecessore fileutils (che è stato combinato con textutils e shellutils a metà degli anni '90 per formare coreutils ). Alcuni elementi del registro delle modifiche possono aiutare a chiarire l'origine della funzione:
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.
Quindi puoi vedere ad esempio che uno degli oggetti d'antiquariato per cui questa funzione era applicabile era SunOS. La corrispondente pagina di manuale diceva questo:
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.
Come notato nella documentazione, questa funzione (e l'opzione corrispondente non sono in POSIX (e vedi il Razionale sezione che spiega perché). Piuttosto, la funzionalità è stata spostata in un nuovo comando (fornito anche da GNU coreutils) chiamato link . La descrizione del comando stesso è vaga; devi leggere la descrizione della chiamata di funzione per ottenere qualsiasi utilizzo dallo standard. Tuttavia, lo standard non chiarisce le condizioni in cui il comando funzionerebbe, a parte portare avanti il disclaimer sui privilegi richiesti. Per questo, devi andare a funzionalità dipendenti dal sistema al di fuori dello standard:
Il collegamento a una directory è limitato al superutente nella maggior parte delle implementazioni storiche perché questa capacità può produrre loop nella gerarchia dei file o danneggiare in altro modo il file system. Questo volume di POSIX.1-2008 continua quella filosofia vietando
link()eunlink()dal fare questo. Altre funzioni potrebbero farlo se l'implementatore ha progettato una tale estensione.
Ci sono sistemi che utilizzano collegamenti fisici a directory oltre il numero normale (2 più sottodirectory).
OSX utilizza collegamenti fisici multipli alle directory per i normali file . Non lo supporta usando ln (vedi pagina di manuale). Secondo How Time Machine Works its Magic, lo fa per fornire le versioni utilizzate per la funzione di backup di Time Machine.
Ulteriori letture:
- Perché OS X Time Machine crea collegamenti fisici alle directory?
- Qual è il comando Unix per creare un collegamento fisico a una directory in OS X?