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
|
|
|
|
Programmation : Assembleur - commande ReadLink (commande DOS de copie des liens)
(Article écrit par Lionel Guillang et extrait d'Amiga News - mai 1993)
|
|
Suite à l'article de Pierre Ardichvili dans un
numéro précédent, il me paraît intéressant de revenir sur les liens et d'approfondir un peu
la question, d'un point de vue programmation.
Flashback
Pour résumer l'épisode précédent, je dirai simplement que les liens sont des fichiers ou
répertoires fantômes qui renvoient des homologues physiques, un peu comme les assignations
et les alias. Mais contrairement à ceux-ci, ils ne sont pas maintenus dans des listes en
RAM par AmigaDOS, mais écrits sur disque (pour plus de détails, reportez-vous
à l'article).
L'avantage évident, c'est qu'il n'est nul besoin de les redéfinir chaque démarrage
du système par d'interminables scripts. Un point important est qu'ils apparaissent
de façon complètement transparente et naturelle à l'utilisateur et au programmeur.
Ainsi, tous les programmes qui "ignorent" leur existence les gèrent, sans s'en
rendre compte (à quelques exceptions près). Mais il y a un inconvénient à cette transparence :
dès que l'on veut traiter des liens en tant que tels, on s'aperçoit très vite qu'ils
sont insaisissables par les techniques classiques (Lock(), Examine(), Open(), etc.).
En effet, le DOS s'emploiera, chaque fois qu'il le peut, à nous tromper ;
ça peut être assez gênant dans certaines applications spécifiques, par exemple
un programme de copie de sauvegarde de disque dur. Il faudra pouvoir "résoudre"
les liens, sans quoi on risque d'avoir des surprises : imaginez la sauvegarde d'un
lien qui renvoie à un répertoire de plusieurs dizaines de Mo. Si le
programme se laisse duper, le dit répertoire sera tout bonnement sauvegardé et
restauré deux fois, entraînant les problèmes que l'on imagine si la partition était
proche de la saturation !
Et alors ?
Le petit programme que je vous propose (ouf, j'y arrive !) permet donc de résoudre les
liens de tout type (matériels et symboliques). Il se présente sous la forme d'une
commande DOS, ReadLink en l'occurrence, à laquelle on transmettra un nom de lien
et qui retournera le chemin complet du répertoire ou fichier physique correspondant.
J'admets que l'utilité d'une telle commande est un peu douteuse, mais cela permet de
faire un exécutable. J'en profite pour faire une petite parenthèse sur quelques petites
absurdités du système 2.0 : le Shell est livré avec une commande MakeLink qui permet
de créer des liens matériels uniquement ; par contre, la doslib contient une fonction,
MakeLink(), qui permet de créer des liens de tout type, et une autre, ReadLink(),
qui permet de résoudre les liens symboliques uniquement ?! Va comprendre, Charles !
Comment ça marche ?
Si le principe est relativement simple, la mise en oeuvre, elle, est un peu fastidieuse.
Après avoir testé la validité de l'argument, on tente un appel à la fonction ReadLink()
qui nous déchargera de tout le travail si on est en présence d'un lien symbolique :
elle retourne le chemin complet (ou une erreur !) et il n'y a plus qu'à l'afficher.
Si ça ne marche pas, c'est que l'argument passé est soit un lien matériel,
soit une entrée physique.
Et c'est là que l'affaire se corse parce que la détermination de l'un ou l'autre des cas n'a rien
de triviale. En effet, si on bloque (lock) puis examine, le DOS nous retournera systématiquement
des informations concernant une entrée physique. Les seules fonctions qui permettraient de
déterminer la nature de l'entrée sont ExNext() et ExAll() ; mais pour pouvoir les utiliser,
il faut déjà avoir un "lock" sur le répertoire parent, qui ne sera pas, dans le cas d'un lien,
le répertoire réel contenant le lien, mais celui contenant l'entrée physique correspondante
(ça va, vous suivez ?)... La solution de l'accès direct aux secteurs n'est pas non plus
très satisfaisante étant donné que, pour les mêmes raisons, il faudrait procéder à une recherche
séquentielle du "bloc header" (en-tête de bloc).
Il n'y a donc aucun moyen, à priori, de résoudre le problème (si quelqu'un a trouvé une parade,
qu'il en fasse profiter la communauté !). C'est pour cette raison que j'ai introduit une condition
obligatoire pour que ReadLink s'y retrouve : un lien ne doit pas porter le même nom que l'entrée
physique à laquelle il correspond. Sur un plan pratique, cela a en plus l'avantage d'éviter de
se prendre les pieds dans le tapis et de ne plus savoir lequel est le vrai et lequel est
le faux.
Pour retrouver le chemin complet de l'entrée physique, on utilise une routine classique de
localisation de répertoire : on remonte jusqu'à la racine de l'arborescence en conservant
les iodes, puis on redescend en examinant chaque répertoire et en concaténant son nom.
Pour déterminer si l'on est en présence d'un lien matériel ou non, on commence par comparer
le système de fichiers du chemin obtenu avec celui de l'argument : s'ils sont différents, ce
ne peut être un lien, Sinon, ultime test, on compare les noms : s'ils sont différents, c'est bien un
lien matériel et on peut afficher le résultat. Voilà, le reste c'est du tout classique.
Notez que pour le même prix, vous avez un exemple d'utilisation de la fonction ReadArgs().
Veinards, va !
Listing
|
