Dalla manpage di 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)
Esistono driver del filesystem che lo consentono effettivamente o è l'unica opzione mount --bind <src> <dest>? O questo tipo di comportamento è bloccato dal kernel prima ancora che arrivi al driver specifico del filesystem?
NOTA: non ho intenzione di farlo su nessuna macchina, sono solo curioso.
Risposte:
In primo luogo una nota: il lncomando non ha opzioni come -d, -F, --directory, questo è un GNUism non portabile.
La funzione che stai cercando è implementata dal link(1)comando.
Torna alla tua domanda originale:
Su un tipico sistema UNIX la decisione, se sono possibili hard link su directory, viene presa nel driver del filesystem.
Il driver UFS di Solaris supporta hard link su directory, il driver ZFS no.
Il motivo per cui UFS su Solaris supporta i collegamenti reali è che AT&T era interessato a questa funzione: UFS di BSD non supporta le directory con collegamenti reali.
Il motivo per cui ZFS non supporta le directory hardlinked è che a Jeff Bonwick non piace quella funzionalità.
Per quanto riguarda Linux, immagino che i blocchi di Linux tentino di creare collegamenti reali su directory nei livelli superiori del kernel. Il motivo di questo presupposto è che Linus Torvalds ha scritto codice per GIT che distruggeva le directory quando git cloneveniva chiamato come root su una piattaforma che supporta le directory hard link.
Notare che un filesystem che supporta la creazione di directory hard link deve anche supportare la unlink(1)rimozione di directory non vuote come root.
Quindi, se assumiamo che Torvalds sappia come funziona Linux e se Linux supportava le directory hard linkate, Torvalds avrebbe dovuto sapere che chiamare unlink(2)una directory pur essendo root, non restituirà un errore ma distruggerà quella directory. In altre parole, è improbabile che Linux consenta a un driver di file system di implementare directory hard link.
La domanda dell'OP cita mount --bind. Un controllo rapido mostra che non modifica il conteggio dei collegamenti per la directory montata. Hardlinking modifica sempre il conteggio dei collegamenti, che puoi vedere usando ls -ld.
Normalmente (la maggior parte dei sistemi simili a Unix), il numero di hardlink a una directory sarà il numero di directory collegate a quel nome, ad es.
".." (la directory principale)"." (la directory stessa)Se leggete il (solito) più informativo informazioni pagina, si può scoprire come gli 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".
sebbene sia attualmente formulato
La maggior parte dei sistemi proibisce di creare un collegamento reale a una directory; su quelli dove è consentito, solo il superutente può farlo (e con cautela, poiché la creazione di un ciclo causerà problemi a molte altre utilità). I collegamenti reali non possono oltrepassare i confini del file system. (Queste restrizioni non sono obbligatorie da POSIX, tuttavia.)
La creazione (e la rimozione) di collegamenti a una directory è una funzione limitata per evitare la perdita di file se una directory non è collegata. Poiché 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 del museo erano ancora in uso. Come notato in Riguardo a Hard Link , originariamente non c'erano chiamate mkdir / rmdir; le directory sono state create (come operazione privilegiata) usando collegamenti reali. Tutto ciò è scomparso quando sono state aggiunte le chiamate di sistema per risolvere i problemi citati. Ma la documentazione continua a fare riferimento a questi sistemi oltre la memoria dei loro manutentori. L'opzione che è stata messa in discussione era nel predecessore fileutils(che è stato combinato con textutilse shellutilsnella metà degli anni '90 per formare coreutils). Alcuni elementi del log 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, ad esempio, puoi vedere che uno degli oggetti d'antiquariato per cui questa funzionalità era applicabile era SunOS. La pagina di manuale corrispondente 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 si trovano in POSIX (e vedere la sezione Razionale che spiega perché). Piuttosto, la funzione è stata spostata in un nuovo comando (fornito anche dai coreutils GNU) chiamato link. La descrizione di il comando stesso è vago; è necessario leggere la descrizione della chiamata di funzione per ottenere qualsiasi uso dallo standard, tuttavia lo standard non chiarisce le condizioni in cui il comando funzionerebbe, oltre a portare avanti la dichiarazione di non responsabilità 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 poiché questa funzionalità può produrre loop nella gerarchia dei file o danneggiare in altro modo il file system. Questo volume di POSIX.1-2008 continua quella filosofia proibendo
link()eunlink()facendo questo. Altre funzioni potrebbero farlo se l'implementatore avesse progettato tale estensione.
Ci sono sistemi che usano collegamenti fisici alle directory al di là del numero normale (2 più sottodirectory).
OSX utilizza più collegamenti fissi a directory per file ordinari . Non supporta questo utilizzando ln(vedere la pagina del manuale ). Secondo come Time Machine funziona in modo magico , lo fa per fornire le versioni utilizzate per la funzione di backup di Time Machine.
Ulteriori letture: