En plus de toutes les autres réponses, je tiens à souligner les propriétés importantes suivantes:
Un lien symbolique est une véritable référence, c’est-à-dire qu’il s’agit d’un petit fichier contenant un chemin. La résolution d'un lien symbolique se produit de manière transparente pour l'application: si un processus ouvre un fichier, par exemple /this/path/here
un lien symbolique pointant vers, /that/other/path
le traitement complet de l'ouverture /that/other/path
est effectué par le système d'exploitation. De plus, s’il /that/other/path
s’agit d’un lien symbolique lui-même, le système d’exploitation le gère également. En fait, le système d’exploitation suit la chaîne de liens symboliques jusqu’à ce qu’il trouve autre chose (par exemple un fichier normal) ou jusqu’à atteindre SYMLOOP_MAX
(voir sysconf(3)
) de nombreuses entrées, auquel cas le système d’exploitation (plus précisément: l’appel système correspondant) renvoie une erreur et définit errno
à ELOOP
. Ainsi, une référence circulaire comme xyz -> xyz
ne bloquera pas le processus. (Pour les systèmes Linux, voir path_resolution(7)
les détails complets.)
Notez qu'un processus peut vérifier si un nom de chemin est un lien symbolique ou non via l'utilisation de lstat(2)
et peut modifier ses attributs de fichier (stockés dans la table inode) via lchown(2)
et d'autres (voir symlink(7)
l'histoire complète).
Maintenant, en termes de permission, vous remarquerez que les liens symboliques ont toujours les permissions 777 ( rwxrwxrwx
en notation symbolique). Ceci est dû au fait que toute autre autorisation peut être contournée en accédant au fichier réel, de toute façon. Inversement, 777 pour un lien symbolique ne rend pas le fichier lié symboliquement accessible s'il n'était pas accessible au départ. Par exemple, un lien symbolique avec des autorisations 777 pointant vers un fichier avec des autorisations 640 ne rend pas le fichier accessible à "autre" (le grand public). En d'autres termes, un fichier xyz
est accessible via un lien symbolique si et seulement si il est directement accessible, c'est-à-dire sans indirection. Ainsi, les autorisations du lien symbolique n'ont aucun effet sur la sécurité.
L'une des principales différences visibles entre les liens durs et les liens symboliques (ou liens symboliques) est que les liens symboliques fonctionnent sur les systèmes de fichiers alors que les liens durs sont limités à un système de fichiers. C'est-à-dire qu'un fichier sur la partition A peut être lié de manière symétrique à partir de la partition B, mais il ne peut pas être lié durement à partir de là. Cela ressort clairement du fait qu’un lien dur est en réalité une entrée dans un répertoire, qui consiste en un nom de fichier et un numéro d’inode, et que les numéros d’inode ne sont uniques que par système de fichiers.
Le terme liaison physique est en réalité quelque peu trompeur. Alors que pour les liens symboliques, la source et la destination sont clairement distinguables (le lien symbolique a sa propre entrée dans la table inode), ce n'est pas le cas pour les liens durs. Si vous créez un lien dur pour un fichier, l'entrée d'origine et le lien dur ne peuvent pas être distingués en termes de ce qui était là en premier. (Puisqu'ils se réfèrent au même inode, ils partagent leurs attributs de fichier tels que propriétaire, autorisations, horodatage, etc.). Ceci conduit à l'affirmation que chaque entrée de répertoire est en fait un lien physique et que lier un fichier en dur signifie simplement en créer un deuxième ( ou troisième, ou quatrième ...) hardlink. En fait, chaque inode stocke un compteur pour le nombre de liens durs vers cet inode.
Enfin, notez que les utilisateurs ordinaires ne peuvent pas créer de liens physiques. En effet, cela doit être fait avec la plus grande prudence: un utilisateur imprudent peut introduire des cycles dans l’arborescence de fichiers par ailleurs strictement hiérarchique, ce à quoi tous les outils habituels (comme fsck
) et le système d’exploitation lui-même ne sont pas préparés.