Tuyau N° 2 : Le lien manquant

une seule : dans la bibliothèque
où réside l’objet. Ce n’est
pas le cas dans les autres systèmes de
fichiers IFS, où les objets « n’appartiennent
» réellement à  aucun répertoire
en particulier – les répertoires sont
simplement des ensembles de liens qui
pointent sur des objets.
La raison de cette dichotomie est
l’architecture objet basée sur les possibilités
de l’OS/400 : les objets ont des
autorités qui peuvent être déléguées,
adoptées et contrôlées de près. Ces autorités
sont mariées à  chaque objet et
ne peuvent pas être mutées sans permission.
En revanche, sous l’IFS, les autorités se trouvent dans des répertoires –
dans les liens vers des objets – pas dans
les objets eux-mêmes. Ce sur quoi
pointe un lien est en réalité un simple
conteneur d’octets. Elle ne possède
pas d’information d’attributs et, par
conséquent, est davantage un fichier
qu’un objet. Il est important de comprendre
cette différence entre le système
de fichiers natif de l’OS/400 et les
autres systèmes de fichiers IFS, pour
comprendre les deux genres de liens
que l’IFS accepte.
Le premier genre de lien, le lien
dur, est une entrée de répertoire normale
qui pointe sur l’emplacement
physique absolu d’un fichier sur
disque. La seule particularité à  propos
des hard links est que n’importe quel
fichier peut en avoir plus d’un – dans la
mesure où tous les hard links se trouvent
dans le même système de fichiers.
Vous utilisez la commande OS/400 Add
Link (ADDLNK) pour créer des liens
additionnels vers un fichier.
Les liens multiples ont une conséquence
intéressante : les fichiers ne
peuvent être supprimés qu’après que
tous les hard links allant vers eux, sauf
un, l’aient été. Quand vous déplacez
un fichier d’un répertoire dans un
autre, le fichier lui-même ne bouge
pas : seul bouge le lien qui y conduit.
Des hard links multiples peuvent
être pratiques quand on veut stocker
une seule copie d’un fichier mais que
de multiples programmes l’atteignent
par leurs propres chemins codés en interne.
Ainsi, vous pourriez avoir un fichier
include nommé mydata, avec des
liens dans les répertoires /myproject/
master/files et /bobsproject/master/
files. Un lien dans chaque répertoire
master/files respectif permet aux
programmes s’exécutant dans des projets
séparés d’accéder tous deux au
même fichier. En y réfléchissant bien,
c’est le même comportement que celui
de l’OS/400 avec des listes de bibliothèques
(et, à  mon avis, le concept liste
de bibliothèques est la meilleure approche).
Le deuxième genre de lien est le
lien symbolique que l’on peut utiliser pour pointer vers des fichiers dans
d’autres systèmes de fichiers. Un lien
symbolique est en réalité un petit fichier
contenant un chemin de répertoire
absolu (commençant par un
signe /) ou partiel (commençant par un
nom de répertoire). Par exemple, un
lien symbolique pourrait pointer directement
vers un fichier :

/myproject/src/main/init.c

Ou un lien symbolique peut pointer
sur un fichier indirectement, d’après le
répertoire courant :

src/main/init.c

Ou un lien symbolique peut pointer
vers un répertoire sans faire vraiment
référence à  un fichier réel :

src/main

Le nom du lien symbolique est arbitraire
(bob.lnk, fred.lnk, mary.lnk,
par exemple). Quand l’IFS rencontre le
nom d’un lien symbolique dans un
chemin, il substitue le contenu du fichier
link à  ce nom dans le chemin.
Ainsi, si bob.lnk contient src/main, un
chemin codé ainsi :

/bobsproject/bob.lnk/init.c

s’étend à 

/bobsproject/src/main/init.c

Ce comportement a une conséquence
pas forcément évidente : un
lien symbolique commençant par un
signe / ignore tout ce qui se trouve
dans le chemin avant ce point. Ainsi, si
bob.lnk contenait /myprojects/src/
main, l’exemple ci-dessus deviendrait

/bobsproject///myproject/src/main/init.c

ce qui signifie en réalité

/myproject/src/main/init.c

Cette petite leçon vous aidera à 
comprendre les problèmes qui surviennent
dans l’IFS quand des liens
sont mal formés ou viennent à  manquer.