Pourquoi les liens physiques ne sont-ils pas autorisés pour les répertoires?
J'utilise Ubuntu 12.04. Lorsque j'essaie de créer un lien en dur pour n'importe quel répertoire, cela échoue. Je peux créer des liens en dur pour les fichiers dans les limites du système de fichiers. Je connais la raison pour laquelle nous ne pouvons pas créer de liens physiques pour les fichiers au-delà du système de fichiers.
J'ai essayé ces commandes:
$ ln /Some/Direcoty /home/nischay/Hard-Directory
hard link not allowed for directory
$ Sudo ln /Some/Direcoty /home/nischay/Hard-Directory
[Sudo] password for nischay:
hard link not allowed for directory
Je veux juste savoir la raison derrière cela. Est-il le même pour toutes les distributions GNU/Linux et les versions Unix (BSD, Solaris, HP-UX, IBM AIX) ou uniquement sous Ubuntu ou Linux?
Le répertoire des liens physiques casse le système de fichiers de plusieurs façons
Ils vous permettent de créer des boucles
Un lien physique vers un répertoire peut être lié à un parent de celui-ci, ce qui crée une boucle de système de fichiers. Par exemple, ces commandes peuvent créer une boucle avec le lien précédent lname__:
mkdir -p /tmp/a/b
cd /tmp/a/b
ln -d /tmp/a l
Un système de fichiers avec une boucle de répertoire a une profondeur infinie:
cd /tmp/a/b/l/b/l/b/l/b/l/b
Éviter une boucle infinie lors de la traversée d'une telle structure de répertoires est un peu difficile (bien que, par exemple, POSIX nécessite findpour éviter cela).
Un système de fichiers avec ce type de lien physique n'est plus une arborescence, car une arborescence ne doit pas, par définition, contenir de boucle.
Ils brisent la clarté des répertoires parents
Avec une boucle de système de fichiers, il existe plusieurs répertoires parents:
cd /tmp/a/b
cd /tmp/a/b/l/b
Dans le premier cas, /tmp/a est le répertoire parent de /tmp/a/b.
Dans le deuxième cas, /tmp/a/b/l est le répertoire parent de /tmp/a/b/l/b, qui est identique à /tmp/a/b.
Il a donc deux répertoires parents.
Ils multiplient les fichiers
Les fichiers sont identifiés par des chemins, après la résolution des liens symboliques. Alors
/tmp/a/b/foo.txt
/tmp/a/b/l/b/foo.txt
sont des fichiers différents.
Il existe une infinité de chemins d'accès au fichier. Ils sont les mêmes en terme de nombre d'inodes. Mais si vous ne vous attendez pas explicitement à des boucles, il n'y a aucune raison de vérifier cela.
Un répertoire hardlink peut également pointer vers un répertoire enfant ou un répertoire qui n'est ni enfant ni parent d'aucune profondeur. Dans ce cas, un fichier enfant du lien serait répliqué dans deux fichiers, identifiés par deux chemins.
Votre exemple
$ ln /Some/Direcoty /home/nischay/Hard-Directory
$ echo foo > /home/nischay/Hard-Directory/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ echo bar >> /Some/Direcoty/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ cat /Some/Direcoty/foobar.txt
foo
bar
Comment les liens symboliques vers les répertoires peuvent-ils alors fonctionner?
Un chemin qui peut contenir des liens symboliques et même des boucles de répertoire liées logiquement est souvent utilisé uniquement pour identifier et ouvrir un fichier. Il peut être utilisé comme un chemin normal et linéaire.
Mais il existe d'autres situations, lorsque les chemins sont utilisés pour comparer des fichiers. Dans ce cas, les liens symboliques dans le chemin peuvent être résolus en premier, en le convertissant en une représentation minimale et convenue de manière commune, créant ainsi un chemin canonique :
Cela est possible car les liens symboliques peuvent tous être étendus à des chemins sans lien. Après avoir fait cela avec tous les liens symboliques d'un chemin, le chemin restant fait partie d'un arbre, où le chemin est toujours sans ambiguïté.
La commande readlinkpeut résoudre un chemin d'accès à son chemin canonique:
$ readlink -f /some/symlinked/path
Les liens symboliques sont différents de ceux utilisés par le système de fichiers
Un lien symbolique ne peut pas causer tous les problèmes car il est différent des liens à l'intérieur du système de fichiers. Il peut être distingué des liens physiques et résolu en un chemin sans liens symboliques si nécessaire.
En un sens, l’ajout de liens symboliques ne modifie pas la structure de base du système de fichiers; il la conserve, mais ajoute davantage de structure, comme une couche d’application.
De man readlink :
NAME
readlink - print resolved symbolic links or canonical
file names
SYNOPSIS
readlink [OPTION]... FILE...
DESCRIPTION
Print value of a symbolic link or canonical file name
-f, --canonicalize
canonicalize by following every symlink in
every component of the given name recursively;
all but the last component must exist
[ ... ]
"De manière générale, vous ne devriez pas utiliser de liens durs" est trop large. Vous devez comprendre la différence entre les liens concrets et les liens symboliques et les utiliser de manière appropriée. Chacune présente ses propres avantages et inconvénients:
Les liens symboliques peuvent:
- Pointez sur les annuaires
- Pointer vers des objets inexistants
- Pointez sur les fichiers et les répertoires situés en dehors du même système de fichiers
Les liens durs peuvent:
- Empêche le fichier référencé d'être supprimé
Les liens physiques sont particulièrement utiles pour effectuer des applications de "copie sur écriture". Ils vous permettent de conserver une copie de sauvegarde d'une structure de répertoires, tout en n'utilisant que de l'espace pour les fichiers échangés entre deux versions.
La commande cp -al est particulièrement utile à cet égard. Il crée une copie complète d'une structure de répertoires dans laquelle tous les fichiers sont représentés par des liens physiques vers les fichiers d'origine. Vous pouvez ensuite procéder à la mise à jour des fichiers dans la structure, et seuls les fichiers que vous mettez à jour occuperont de l'espace supplémentaire. Ceci est particulièrement utile lors de la maintenance de sauvegardes multigénérationnelles.
Pour votre information, vous pouvez obtenir la même chose que des liens physiques pour des répertoires en utilisant mount:
mount -t bind /var/www /home/user/workspace/www
Ceci est très dangereux car la plupart des outils et programmes ne connaîtront pas la liaison. Une fois, j'ai fait quelque chose comme dans l'exemple ci-dessus, puis je suis passé à rm -rf /home/user. Heureusement, il n'y avait rien de pertinent dans /var/www.
La raison pour laquelle les répertoires physiques ne sont pas autorisés est un peu technique. Essentiellement, ils cassent la structure du système de fichiers . De toute façon, vous ne devriez généralement pas utiliser de liens physiques. Les liens symboliques permettent la plupart des mêmes fonctionnalités sans causer de problèmes (par exemple ln -s target link).