Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Dossier : Liens matériels, liens symboliques
(Article écrit par Pierre Ardichvili et extrait d'Amiga News - mars 1993)
|
|
Introduction
AmigaOS 2.0 a introduit une nouvelle notion, celle de liaisons. Certains disent
aussi "liens". Nous nous conformerons ici à la terminologie du manuel livré par
Commodore avec AmigaOS. Le mot "liaison" désigne le fichier qui établit le
lien. Un lien est aussi bien l'équivalent pour des fichiers de données, de l'alias
pour les fichiers exécutables.
On crée un fichier de liaison, appelons-le FLECHE, qui ne fait que pointer sur un
fichier de destination. Appelons-le CIBLE. Pour commencer par les choses
simples, on dispose pour ce faire de la commande "Makelink"
d'AmigaOS, dont la syntaxe est dans le cas de figure :
CIBLE est ici ce que l'on appelle un nom complet, c'est-à-dire comprenant le chemin complet
de CIBLE s'il n'est pas dans le répertoire courant.
Lorsqu'un programme quelconque
(une commande AmigaOS, un éditeur ou tout programme susceptible d'utiliser le fichier de données CIBLE)
recevra comme argument FLECHE, il traitera en fait le fichier CIBLE. Ceci peut être très
commode peur appeler un fichier enfoui dans une profonde arborescence de répertoires, ou pour faire
en sorte de ne pas devoir modifier le programme si l'on déplace le fichier CIBLE.
On peut créer une liaison vers un fichier ou vers un répertoire. Dans ce dernier
cas, la commande "Makelink" demande l'option FORCE.
Liaisons matérielles et liens symboliques
Le lien décrit ci-dessus est qualifié de lien matériel car il concerne deux fichiers
situés sur le même volume. La commande AmigaOS "Makelink" ne traite que de ce type de liens. Il
existe aussi des liens symboliques. La différence tient à la manière de réaliser le lien.
Un fichier AmigaOS comporte un bloc dit "File Header", normalement suivi de blocs contenant
les données proprement dites. Lorsque l'on établit un lien matériel, par exemple par
la commande "Makelink", AmigaOS place dans les octets 01D6 et 01D7 (vers le milieu de la
dernière ligne du bloc) du fichier origine le numéro du bloc dans lequel se trouve le
File Header du fichier destination. Cette information est amplement suffisante car le
fichier destination se trouve sur la même unité physique. Par ailleurs, le fichier origine
ne comporte qu'un File Header et aucun bloc de données, c'est pourquoi il apparaît comme un fichier
de taille nulle.
Le lien symbolique est plus souple, car le File Header du fichier liaison comporte,
juste à la suite de ses octets de somme de contrôle, et sous la forme d'une chaîne
ASCII, le chemin complet du fichier de destination, que ce dernier fichier réside
ou non sur le même volume. Les liens symboliques ne peuvent être créés que par
un appel à la fonction "MakeLink()" dans un programme.
Complications
Structure des fichiers
A part leur taille nulle et le fait qu'ils ne comportent qu'un bloc File
Header et aucun bloc de données, les liaisons matérielles sont des fichiers
de données classiques, de type FFFC ou -4. Ils apparaissent donc comme des fichiers normaux
dans l'affichage qui suit une commande Dir, List ou autre. Par contre,
pourquoi diable les liaisons symboliques ont-elles un code de type 3,
qui est celui des répertoires ?
Le commentaire que l'on trouve dans "dosextens.h" est d'ailleurs savoureux : "looks like dir,
but may point to a file!". Elles apparaissent par conséquent comme des répertoires dans
les affichages dont nous venons de parler, mais il n'est évidemment pas question de faire
un CD ou un Dir dessus, sauf bien sûr si la destination du lien est elle-même un répertoire.
Aspirine SVP.
AmigaOS réagit d'ailleurs par un message approprié, sans dommage. Pas question non plus
d'examiner ces fichiers au moyen d'un éditeur binaire en les appelant par leur nom, on
tombe nécessairement sur la visualisation du fichier destination. Il faut utiliser le
bon vieux DiskX ou la dernière version de AZap et trouver le numéro du bloc File Header du
fichier de liaison à examiner.
Considérations logiques
La différence de réalisation des liens matériels et symboliques est à l'origine d'un comportement
différent lors de la restauration.
J'établis un lien de dh0:fleche vers dh0:placard/cible, et je sauvegarde dh0:.
Qu'il s'agisse d'un lien matériel ou symbolique, si je restaure vers dh0:,
le résultat sera le même. Par contre, si je restaure vers une autre partition dh1:,
dans le cas d'une liaison matérielle, j'obtiendrai une liaison dh1:fleche qui
pointera vers dh1:placard/cible. En effet, le contenu de dh1:fleche se réduit à un numéro de bloc,
implicitement dans le même volume.
Dans le cas d'une liaison symbolique, le contenu de dh1:fleche est la chaîne ASCII
"dh0:placard/cible", et le lien pointe sur un fichier destination situé dans dh0:.
Ceci est d'ailleurs sans doute la raison peur laquelle la commande "Makelink"
d'AmigaOS ne traite normalement que les liens matériels, moins délicats à traiter.
Comportement des programmes
Les logiciels de copie de sauvegarde Quarterback, Ami-Back et ABackup (à l'exception de certaines versions, dont la 2.10)
traitent correctement les liens matériels et symboliques.
Ces trois programmes refusent de sauvegarder ou de restaurer les liens si les
fichiers de destination soit ne sont pas compris dans la sélection de la
sauvegarde, soit, dans le cas de liens symboliques vers d'autres volumes, si
le fichier destination n'est pas présent. Les différences tiennent à l'affichage.
Les messages d'erreur sont variables, je signale simplement que les listings d'erreur
fournis par Ami-Back sont parfois sibyllins et incomplets.
Par contre, la documentation d'Ami-Back met clairement l'utilisateur en garde au sujet de la
restauration des liens matériels sur une autre unité logique. La documentation de Quarterback
ne souffle pas un mot sur les liens. ABackup offre dans ses menus de configuration l'option de
prendre les liens en compte ou de les ignorer.
Lha, du moins la version dont je dispose, ne reconnaît pas les liens symboliques :
dans le cas de liens matériels, comme on peut s'y attendre, il inclut dans
l'archive, sous le nom du fichier liaison, le contenu du fichier destination.
Quant à Ami'FastBack, comme d'ailleurs Ami-Back en mode image, il est évident
qu'il sauvegarde le fichier liaison tel quel, mais sans aucune vérification quant à l'existence du fichier
destination.
Conclusion
La sauvegarde et la restauration des liens matériels ou symboliques peut causer
des surprises, mais ne devrait pas poser de problèmes sérieux ; elle demande certaines précautions, la
meilleure étant d'avoir une bonne compréhension du fonctionnement des liens.
|
