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 : Fast Fast System/New Filing System
(Article écrit par Cédric Beust et extrait d'A-News (Amiga News) - mai 1990)
|
|
Un système de fichiers aussi pour disquettes
Le nouveau système de fichiers (NFS, New Filing System) est basé sur le FFS. Sa principale différence avec
celui-ci est qu'il s'applique désormais aux disquettes. Pour des raisons de compatibilité, il peut néanmoins
lire l'ancien format. On peut s'attendre à voir la vitesse de parcours de répertoire sensiblement améliorée
mais les vitesses de lecture et écriture iront à peine plus vite qu'avec l'ancien système d'exploitation.
Ceci est dû au fait que le NFS émule complètement l'ancien format, allant jusqu'à lire l'en-tête spéciale des
blocs de données ce qui l'oblige à lire les blocs un à un. En mode rapide (DosType = DOS1), le NFS ira au
moins aussi vite que le FFS de la version 1.3.
Étant donné que le NFS émule désormais deux formats différents, la façon dont le champ DosType est interprété
peut varier. En bref, quand aucun autre renseignement n'est disponible, le NFS prendra par défaut le DosType
lu dans la liste de montage du disque (ou de la partition) courant (dans le cas d'une disquette, c'est DOS0).
Cependant, si une disquette DOS1 est insérée dans le lecteur, le NFS utilisera les informations lues sur le
bloc d'amorce pour surpasser celles de la liste de montage. Il sera également possible de formater des disquettes
en FFS, ce qui aura pour effet d'ignorer le DosType par défaut et de prendre les informations données en
paramètres lors du formatage.
Les nouvelles fonctions
Passons maintenant en revue les nouvelles fonctions.
Verrouillages
Il est désormais possible de verrouiller certaines parties des fichiers en cours d'utilisation. Je rappelle qu'il
existe deux types de verrous : ceux en lecture, indiquant que n'importe quel autre processus peut lire le fichier
ainsi verrouillé (et donc poser un verrou de ce même type) et ceux en écriture : il s'agit alors d'un verrou exclusif
et aucun autre processus ne peut ni lire ni écrire le fichier.
Bien qu'apparemment compliqué, ce système est très simple : quand vous lisez un fichier, il est normal que personne
ne puisse le modifier mais logique que d'autres puissent le lire en même temps. En revanche, quand vous le modifiez,
il vaut mieux que personne ne puisse faire de même, ni même le lise étant donné que les informations sont en cours de changement.
Les verrous dans l'ancien système ne pouvaient s'appliquer qu'aux fichiers dans leur intégralité. Ceci posait
un problème dans le cas de bases de données sur réseau par exemple : on ne travaille que sur un article à la fois.
Pourquoi verrouiller dans ce cas l'intégralité du fichier ? Le verrouillage d'article (ou plus exactement de
certaines portions du fichier) peut être utilisé sur n'importe quel fichier, quel que soit le mode utilisé pour
l'ouvrir. Ce sera en général le MODE_OLDFILE (verrou partagé, ou en lecture) ou bien avec une combinaison de
MODE_ONE_WRITER et MODE_READ_ONLY. Il ne semble pas très judicieux de l'employer sur des fichiers ouverts en
MODE_NEWFILE (création et modification de fichier) étant donné que le verrou exclusif qui lui est automatiquement
attaché écarte toute nécessité d'arbitrer un éventuel accès multiple.
Deux fonctions font leur apparition pour gérer le verrouillage partiel : LockRecord() et FreeRecord(), dont voici
une brève description :
succès = LockRecord(fichier, position, longueur, mode, délai)
d0 d1 d2 d3 d4 d5
|
succès = FreeRecord(fichiers, position, longueur)
d0 d1 d2 d3
|
Un nouveau message d'erreur peut se produire lors d'une tentative de Read() ou Write() : ERROR_RECORD_LOCKED (244),
dans le cas où un verrou exclusif a été posé sur le fichier. Il est important d'utiliser dans ces deux opérations
le même descripteur de fichier que celui utilisé pour le verrouiller.
Fonctions diverses
Beaucoup de développeurs ont exprimé le désir d'avoir la possibilité de tronquer la taille d'un fichier ou,
à l'inverse, de pouvoir l'agrandir à une taille donnée. Plutôt que de fournir deux fonctions distinctes pour
répondre à ce besoin, une unique fonction a été proposée qui remplira les deux buts. Cette fonction s'appelle
SetFileSize().
succès = SetFileSize(fichier, position, mode)
d0 d1 d2 d3
|
Par exemple, SetFileSize(fichier, 0, OFFSET_CURRENT) déclare que la taille du fichier doit être étendue de
0 à partir de la position courante. Cela fixe donc sa taille à la position actuelle du curseur (seek position).
Pour imposer à un fichier de ne faire que 100 octets, on utiliserait la commande SetFileSize(fichier, 100, OFFSET_BEGIN).
Il est parfois utile d'obtenir des informations sur un fichier qui a déjà été ouvert en utilisant son nom
(sous forme de chaîne). Malheureusement, la plupart des fonctions DOS de ce type ne prennent comme argument
qu'un Lock. Étant donné que Open() retourne un BPTR sur un descripteur de fichier, cela n'était jusqu'à
présent pas chose aisée, aussi une nouvelle fonction a été ajoutée : LockFromFH(). Cette fonction permet
l'équivalent de DupLock() mais à partir d'un descripteur de fichier. Il n'est pas possible d'obtenir un
Lock sur un fichier ouvert en mode MODE_NEWFILE étant donné que le verrou ainsi obtenu est exclusif. Le
verrou retourné par LockFromFH() est donc partagé.
verrou = LockFromFH(fichier)
d0 d1
|
Afin de maintenir une certaine symétrie dans la bibliothèque DOS, la fonction inverse a également été créée.
En gros, elle fait un Open() sur un fichier avec un Lock obtenu par l'appelant. Le type du verrou détermine
le mode dans lequel le fichier sera ouvert. Remarque : si un verrou EXCLUSIVE_LOCK ou ONE_WRITER est utilisé
de cette façon, le fichier ne sera pas créé étant donné qu'il doit déjà exister afin de pouvoir obtenir
un verrou. Quand le FileHandle retourné par cette fonction est fermé, c'est à l'appelant qu'incombe la
responsabilité de libérer le verrou. Il ne faut pas libérer ce verrou avant que le fichier ait été fermé !
fichier = FHFromLock(verrou)
d0 d1
|
La notion de notification a été étendue. Par ce terme, on entend le fait qu'un application peut désirer
être informée quand tel ou tel fichier a été modifié. La version précédente du système d'exploitation
ne laissait que peu de possibilités à ce niveau : la seule notification que l'on pouvait exiger était celle
d'un changement des préférences (en utilisant le drapeau IDCMP NEWPREFS). Il est désormais possible de
demander une notification sur n'importe quel fichier. Je ne vais pas m'étendre davantage sur le fichier
puisque cela est expliqué largement dans l'article consacré aux préférences 2.0.
La version 2.0 autorise la création de liens entre fichiers. Le NFS permet désormais la création de liens
durs (attention : sous AmigaDOS, les liens matériels et symboliques n'ont pas la même signification que "Hard Links"
et "Soft Links" sous Unix : les "Soft Links" d'AmigaDOS permettent de lier des fichiers
sur des volumes différents, ce que ne permettent pas les "Hard Links"). Cette fonction est très utile et
permet de simplifier les références à des structures de répertoires très imbriquées. Par exemple, un fichier
a/b/c/d/e/f/g/the_paranoid_android pourrait être lié à un "faux" fichier a/Marvin et référencé sous ce
dernier nom dans des programmes. Contrairement aux assignements logiques, un lien devient partie intégrante
de la structure du fichier et ne disparaît pas quand le système est redémarré.
Effacer un lien n'efface pas le fichier auquel il se réfère : le lien est brisé et l'entrée est effacée
(Marvin dans l'exemple précédent). Attention : effacer des fichiers qui possèdent des liens laisseront
ces liens dans d'autres répertoires.
succès = MakeLonk(nom, verrou, soft
d0 d1 d2 d3
|
|
