J'ai été invité récemment au cours d'une entrevue d'emploi. J'ai été honnête et a dit que je savais comment faire un lien symbolique se comporte et comment en créer un, mais ne comprennent pas l'utilisation d'un lien en dur et en quoi elle diffère d'une symbolique.
Réponses
Trop de publicités?
Sous le système de fichiers les fichiers sont représentés par des inodes (ou de plusieurs des inodes pas sûr)
Un fichier dans le système de fichier est en fait un lien vers un inode.
Un lien en dur puis il suffit de crée un autre fichier avec un lien vers le même sous-jacent de l'inode.
Lorsque vous supprimez un fichier, il supprime un lien vers le sous-jacent de l'inode. L'inode n'est supprimé (ou supprimables/sur-les droits d'écriture) lorsque toutes les liaisons vers l'inode ont été supprimés.
Un lien symbolique est un lien vers un autre nom dans le système de fichiers.
Une fois un lien en dur a été fait, le lien est vers l'inode. supprimer renommer ou déplacer le fichier d'origine n'affectera pas le lien en dur car elle est reliée à la sous-jacentes de l'inode. Toute modification des données sur l'inode est reflétée dans tous les fichiers qui se réfèrent à cet inode.
Remarque: des liens en Dur ne sont valables que dans le même Système de Fichiers. Les liens symboliques peuvent s'étendre sur des systèmes de fichiers comme ils sont tout simplement le nom d'un autre fichier.
Adam Matan
Points
15690
Quelques belles intuition qui pourrait aider, en utilisant toutes les versions de Linux(ish) de la console.
Créer deux fichiers:
$ touch blah1; touch blah2
Entrer quelques Données:
$ echo "Cat" > blah1
$ echo "Dog" > blah2
(En fait, j'aurais pu utiliser echo en premier lieu, il crée les fichiers s'ils n'existent pas... mais jamais l'esprit.)
Et comme prévu:
$cat blah1; cat blah2
Cat
Dog
Nous allons créer durs et mous de liens:
$ ln blah1 blah1-hard
$ ln -s blah2 blah2-soft
Voyons voir ce qui s'est passé:
$ ls -l
blah1
blah1-hard
blah2
blah2-soft -> blah2
Changer le nom de blah1 n'a pas d'importance:
$ mv blah1 blah1-new
$ cat blah1-hard
Cat
blah1-points durs de l'inode, le contenu de la file - qui n'a pas été changé.
$ mv blah2 blah2-new
$ ls blah2-soft
blah2-soft
$ cat blah2-soft
cat: blah2-soft: No such file or directory
Le contenu du fichier n'a pas pu être trouvé, parce que le doux lien pointe vers le nom, qui a été modifié, et de ne pas le contenu. De même, Si blah1 est supprimé, blah1-dur détient toujours le contenu; si blah2 est supprimé, blah2-soft est juste un lien vers un fichier non-existant.
Tanktalus
Points
7940
Des liens en dur sont utiles lorsque le fichier d'origine est de se déplacer autour. Par exemple, le déplacement d'un fichier de /bin et /usr/bin ou /usr/local/bin. Tout lien symbolique vers le fichier dans /bin serait brisé par la présente, mais un hardlink, un lien directement vers l'inode du fichier, ne serait pas de soins.
Des liens en dur peut prendre moins d'espace disque qu'ils ne prennent une entrée de répertoire, alors qu'un lien symbolique a besoin de sa propre inode pour stocker le nom il indique.
Des liens en dur également prendre moins de temps pour résoudre des liens symboliques peuvent pointer vers d'autres liens symboliques qui sont liés par un lien symbolique répertoires. Et certains d'entre eux pourraient être sur NFS ou autre haut-de latence des systèmes de fichiers, et peut entraîner un réseau de trafic pour les résoudre. Liens en dur, d'être toujours sur le même système de fichiers, sont toujours résolus en un seul regard, et n'impliqueront pas de la latence du réseau (si c'est un hardlink sur un système de fichiers NFS, le serveur NFS ferait la résolution, et il serait invisible pour le système client). Parfois, c'est important. Pas pour moi, mais je peux imaginer des systèmes à haute performance où cela peut être important.
Je pense aussi que des choses comme mmap(2) et même ouvrir la porte(2) utiliser les mêmes fonctionnalités que les liens de garder un inode du fichier actif de sorte que même si le fichier est unlink(2)ed, l'inode reste à permettre le déroulement continu d'accès, et seulement une fois que le processus se termine, il ne le fichier vraiment aller loin. Cela permet beaucoup plus sûr fichiers temporaires (si vous pouvez obtenir les ouvrir et de les dissocier pour arriver atomiquement, il peut y avoir une API POSIX pour que je ne me rappelle pas, alors vous avez vraiment un coffre-fort de fichiers temporaires) où vous pouvez lire/écrire vos données sans que personne puisse y accéder. Eh bien, c'était vrai avant /proc a donné à chacun la possibilité de regarder votre descripteurs de fichiers, mais c'est une autre histoire.
En parlant de qui, de récupérer un fichier qui est ouvert dans Un processus, mais sans liens sur le système de fichiers tourne autour de l'utilisation des liens physiques pour recréer l'inode liens afin que le fichier ne veut pas s'en aller quand le processus qui a ouvert il se ferme ou s'en va.
Prabhat Kumar Singh
Points
21
Doux Lien:
doux ou symbolique est plus un raccourci vers le fichier d'origine....si vous supprimez l'original le raccourci échoue et si vous ne pouvez supprimer le raccourci ne se passe rien à l'original.
Note: les liens Symboliques peuvent s'étendre sur des systèmes de fichiers comme ils sont tout simplement le nom d'un autre fichier. Alors que des liens en dur ne sont valables que dans le même Système de Fichiers.
Doux lien de la Syntaxe: ln -s fichier1 fichier2
Lien Dur:
Lien en dur est plus d'une copie miroir ou plusieurs chemins vers le même fichier. Faire quelque chose pour fichier1 et il apparaît dans le fichier 2. La suppression d'un garde encore les autres ok.
L'inode(ou fichier) n'est supprimé lorsque tous les (dur)des liens ou tous les chemins d'accès à la (même fichier)inode a été supprimé.
Une fois un lien en dur a été fait le lien a l'inode du fichier d'origine. Supprimer renommer ou déplacer le fichier d'origine n'affectera pas le lien en dur car elle est reliée à la sous-jacentes de l'inode. Toute modification des données sur l'inode est reflétée dans tous les fichiers qui se réfèrent à cet inode.
Lien en dur syntaxe: ln fichier1 fichier2
Les liens symboliques ont certaines caractéristiques des liens en dur sont manquants:
- Lien en dur point le contenu du fichier. tout Doux lien pointe vers le nom de fichier.
- bien que la taille de lien en dur est la taille du contenu, tout doux lien est avoir le nom de fichier de la taille.
- Des liens en dur de partager le même inode. Des liens ne pas.
- Des liens en dur ne peut pas traverser les systèmes de fichiers. Doux liens ne.
- vous savez immédiatement où un lien symbolique pointe tout dur des liens, vous avez besoin d'explorer le système de fichiers entier pour trouver des fichiers partageant le même inode.
- hard-links ne peut pas pointer vers des répertoires.
Pourquoi dur liens ne peuvent franchir les systèmes de fichiers ou des partitions:
Sur un disque dur il y a beaucoup de secteurs.
Dire un fichier commence à inode (secteur) 4001 et se termine à 5000. Le fichier "/export/home/john/mail.doc"
Alors: 1. Un lien en dur "mail.doc" ce qui est nommé "hardLinkToMail" contient la valeur: "4001". 2. Un doux lien "mail.doc" ce qui est nommé "softLinkToMail" contient la valeur: "/export/home/john/mail.doc".
1) le lien en dur ne peut pointer que sur le même disque. Il ne peut pas pointer vers un autre lecteur. Tous les lecteurs a un inode de valeur "4001", comment le lien en dur de distinguer entre tous les disques? Le lecteur qui "4001" est-il?
2) le doux lien contient une chaîne de caractères. La chaîne peut point à un autre système de fichiers sur un autre disque, car le chemin d'accès complet est spécifié.
Andrew Medico
Points
11338
Les liens symboliques lien vers un nom de chemin d'accès. Cela peut être n'importe où dans un système de fichiers de l'arbre, et ne disposent même pas d'exister lorsque le lien est créé. Le chemin de la cible peut être relative ou absolue.
Des liens en dur sont des pointeurs supplémentaires à un inode, ce qui signifie qu'ils peuvent exister que sur le même volume que la cible. Supplémentaire des liens en dur vers un fichier sont impossibles à distinguer de l ' "original" nom utilisé pour faire référence à un fichier.
