Code Search for Developers
 
 
  

014.html from Gulus at Krugle


Show 014.html syntax highlighted

<HTML><HEAD><TITLE>Linux-Mandrake: Guide de l'utilisateur et Manuel de référence</TITLE>
<LINK REV=MADE HREF="mailto:info@mandrakesoft.com"></HEAD>
<BODY BGCOLOR="#ffffff"><center><font size="+5"><STRONG><table border="0"><tr><td><STRONG>Linux-Mandrake</STRONG>:</td></tr><tr><td>Guide de l'utilisateur</td></tr><tr><td>et Manuel de référence</td></tr></table></STRONG></font>

<p><font size="+2"><STRONG><table border="0"><tr><td><STRONG>MandrakeSoft</STRONG></td></tr></table></STRONG></font>

<p><STRONG><table border="0"><tr><td>&nbsp;</td></tr><tr><td>&nbsp;</td></tr><tr><td>Janvier 2000</td></tr><tr><td><CODE>http://www.linux-mandrake.com</CODE></td></tr><tr><td></td></tr></table></STRONG></center>
<hr><a href="015.html">Suivant&nbsp;: Le système de fichiers <CODE>/proc</CODE></a><br><a href="013.html">Précédent&nbsp;: Organisation de l'arborescence des fichiers</a><br><a href="../">Retour</a><br><hr><a href="000.html#toc"><font size="-1">(Retour à la table des matières)</font></a>


<H1><font size="+1"><a name="128">Chapitre 4&nbsp;: Le système de fichiers de <STRONG>Linux</STRONG>: <STRONG>ext2fs</STRONG> (<EM>EXTended 2 FileSystem</EM>)</a></font></H1><hr><p>Le <EM>Guide de l'utilisateur</EM> a introduit les concepts de propriété des fichiers
et les droits d'accès, mais pour vraiment comprendre le <STRONG>système
de fichiers</STRONG> de <STRONG>Linux</STRONG>, il faut redéfinir la notion même de
fichier.  Une raison en est que:


<H1><a name="129">Tout est fichier</a></H1>

<p>Ici, «&nbsp;tout&nbsp;» veut dire <EM>vraiment</EM> tout. Un disque dur,
une partition sur un disque dur, un port parallèle, une connexion à un
site <EM>web</EM>, une carte <EM>Ethernet</EM>, tous ces éléments sont des
fichiers. Même les répertoires sont des fichiers. <STRONG>Linux</STRONG>
reconnaît plusieurs types de fichiers, en plus des fichiers réguliers et
des répertoires.  Notez que par type de fichier ici, nous ne faisons pas
référence au type du <EM>contenu</EM> du fichier: pour <STRONG>Linux</STRONG> et
pour tout système <STRONG>Unix</STRONG>, un fichier, qu'il soit une image <EM>GIF</EM>,
un fichier binaire ou autre, est juste une suite d'octets. La
différenciation des fichiers en fonction de leur contenu est laissé aux
applications.

<p>Si vous vous souvenez, quand vous tapez <CODE>ls -l</CODE>, le caractère
avant les droits d'accès représente le type du fichier. Nous avons déjà
vu deux types de fichiers: les fichiers réguliers (<CODE>-</CODE>) et les
répertoires (<CODE>d</CODE>). Vous pouvez aussi tomber sur les suivants si
vous vous baladez dans l'arborescence et listez le contenu des
répertoires:


<ul><li><STRONG><STRONG>Fichiers en mode caractère</STRONG></STRONG>:  Ces fichiers sont soit des
fichiers spéciaux du système (comme <CODE>/dev/null</CODE>, que nous avons
déjà vu), ou des périphériques (ports série ou parallèle), qui ont en
commun la particularité que leur contenu (s'ils en ont) n'est pas
conservé en mémoire<a name="bodynote13" href="026.html#note13">[13]</a>.  De tels fichiers sont identifiés
par la lettre <CODE>'c'</CODE>.
<li><STRONG><STRONG>Fichiers en mode bloc</STRONG></STRONG>:  Ces fichiers sont des
périphériques, et à l'opposé des fichiers en mode caractère, leur
contenu <EM>est</EM> sauvegardé en mémoire. Les fichiers entrant dans
cette catégorie sont, par exemple, les disques durs, les partitions sur
un disque dur, les lecteurs de disquettes et de <EM>CD-ROM</EM>, et ainsi de
suite. Les fichiers <CODE>/dev/hda</CODE>, <CODE>/dev/sda5</CODE> sont des exemples
de fichiers en mode bloc. Sur la sortie d'un <CODE>ls -l</CODE>, ces
fichiers sont identifiés par la lettre <CODE>'b'</CODE>.
<li><STRONG><STRONG>Liens symboliques</STRONG></STRONG>:  Ces fichiers sont très courants, et
très utilisés dans la procédure de démarrage de <STRONG>Linux-Mandrake</STRONG> (voyez
le chapitre&nbsp;16.0). Comme leur nom l'indique, leur but est de
lier des fichiers de façon symbolique, ce qui veut dire que de tels
fichiers peuvent ou non pointer sur un fichier existant. Ceci est
expliqué plus loin dans ce chapitre. Ils sont très souvent appelés
<STRONG><EM>soft links</EM></STRONG> en anglais, et sont identifiés par la
lettre <CODE>'l'</CODE>.
<li><STRONG><STRONG>Tubes nommés</STRONG></STRONG>:  Au cas où vous vous le demanderiez, oui,
ils sont très similaires aux tubes utilisés par le <EM>shell</EM>, mais
avec la particularité que ceux-ci ont un nom. Lisez la suite pour en
savoir plus. Toutefois, ils sont très rares, et il est peu probable que
vous en voyiez un durant votre voyage dans l'arborescence. Juste au cas
où, la lettre qui les identifie est <CODE>'p'</CODE>.
<li><STRONG><STRONG><EM>Sockets</EM></STRONG></STRONG>:  C'est le type de fichier pour toutes
les connexions réseau. Mais seules quelques-unes<a name="bodynote14" href="026.html#note14">[14]</a> d'entre elles portent des
noms. Pour compliquer les choses, il existe plusieurs types de
<EM>sockets</EM>, mais cela est bien au-delà de l'objectif de ce livre.
Des tels fichiers sont identifiés par la lettre <CODE>'s'</CODE>.</ul>

<p>Voici un exemple de chacun de ces fichiers:

<p><font size="-4"><PRE>
$ ls -l /dev/null /dev/sda  /etc/rc.d/rc3.d/S20random /proc/554/maps \
  /tmp/ssh-fg/ssh-510-agent
crw-rw-rw-    1 root     root       1,   3 mai  5  1998 /dev/null
brw-rw----    1 root     disk       8,   0 mai  5  1998 /dev/sda
lrwxrwxrwx    1 root     root           16 déc  9 19:12 /etc/rc.d/rc3.d/S20random -&gt;
../init.d/random*
pr--r--r--    1 fg       fg              0 déc 10 20:23 /proc/554/maps|
srwx------    1 fg       fg              0 déc 10 20:08
/tmp/ssh-fg/ssh-510-agent=
$
</PRE></font>

<p>On devrait ajouter que <STRONG>ext2fs</STRONG>, comme tous les autres systèmes de
fichiers <STRONG>Unix</STRONG>, stocke les fichiers, quel que soit leur type,
dans une table des <STRONG>i-noeuds</STRONG>. Une particularité est qu'un
fichier n'est pas identifié par son nom, mais par un numéro
d'i-noeud. En fait, certains fichiers n'ont pas de noms. Les noms
sont juste une conséquence d'une notion plus large:


<H1><a name="130">Les liens</a></H1>

<p>Le meilleur moyen de comprendre ce qui se cache derrière cette notion de
liens est de prendre un exemple. Créons un fichier (régulier):

<p><font size="-3"><PRE>
$ pwd
/home/fg/exemple
$ ls
$ touch a
$ ls -il a
  32555 -rw-rw-r--    1 fg       fg              0 déc 10 08:12 a
</PRE></font>

<p>L'option <CODE>-i</CODE> de la commande <CODE>ls</CODE> affiche le numéro
d'i-neud, qui est le premier champ dans la sortie. Comme vous pouvez le
voir, avant que nous ayons créé le fichier <CODE>a</CODE>, il n'y avait aucun
fichier dans le répertoire. L'autre champ intéressant est le troisième,
qui est le compteur de liens pour le fichier.

<p>En fait, on peut séparer la commande <CODE>touch a</CODE> en deux actions
distinctes:


<ul><li>création d'un i-noeud, auquel le système a attribué le numéro
32555, dont le type est celui d'un fichier régulier,
<li>création d'un lien vers cet i-noeud, nommé <CODE>a</CODE>, dans le
répertoire courant, <CODE>/home/fg/exemple</CODE>. Donc, le fichier appelé
<CODE>/home/fg/exemple/a</CODE> est un lien vers l'i-noeud de numéro 32555,
et c'est pour l'instant le seul: le compteur de liens est à 1.</ul>

<p>Mais maintenant, si nous faisons:

<p><font size="-3"><PRE>
$ ln a b
$ ls -il a b
  32555 -rw-rw-r--    2 fg       fg              0 déc 10 08:12 a
  32555 -rw-rw-r--    2 fg       fg              0 déc 10 08:12 b
$
</PRE></font>

<p>nous avons créé un autre lien vers le même i-noeud. Comme vous pouvez
le voir, nous n'avons créé aucun fichier nommé <CODE>b</CODE>, mais au lieu de
cela nous avons ajouté un autre lien vers l'i-noeud de numéro 32555
dans le même répertoire nommé <CODE>b</CODE>. Vous pouvez voir dans la
deuxième sortie de <CODE>ls -l</CODE> que le compteur de liens est
maintenant 2 et non plus 1.

<p>Maintenant, si nous faisons:

<p><font size="-3"><PRE>
$ rm a
$ ls -il b
  32555 -rw-rw-r--    1 fg       fg              0 déc 10 08:12 b
$
</PRE></font>

<p>nous voyons que même si nous avons effacé le «&nbsp;fichier
original&nbsp;», l'i-noeud existe encore. Mais maintenant le seul lien vers
cet i-noeud est <CODE>/home/fg/exemple/b</CODE>.

<p>Donc, un i-noeud est <STRONG>lié</STRONG> si et seulement si il est référencé
par un nom au moins une fois dans un répertoire quelconque<a name="bodynote15" href="026.html#note15">[15]</a>.
Les répertoires eux-mêmes sont aussi stockés dans des i-noeuds, mais
leur compteur de liens, contrairement à tous les autres types de
fichiers, est leur nombre de sous-répertoires. Il y a au moins deux
liens par répertoire: le répertoire lui-même (<CODE>.</CODE>) et son
répertoire parent (<CODE>..</CODE>).

<p>Des exemples typiques de fichiers qui ne sont pas liés (c'est-à-dire
qu'ils n'ont pas de noms) sont les connexions réseau: vous ne verrez
jamais le fichier correspondant à votre connexion à
<CODE>www.linux-mandrake.com</CODE> dans votre arborescence, quel que soit le
répertoire que vous essayiez. De façon similaire, quand vous utilisez un
<STRONG>tube</STRONG> dans le <EM>shell</EM>, le fichier correspondant au tube
existe bien, mais il n'est pas lié.


<H1><a name="131">Tubes «&nbsp;anonymes&nbsp;» et tubes nommés</a></H1>

<p>Revenons à l'exemple des tubes, car il est très intéressant et c'est
également une bonne illustration de la notion de liens. Quand vous
utilisez un tube dans une ligne de commande, le <EM>shell</EM> crée le
tube pour vous et fait en sorte que la commande avant le tube écrit dans
celui-ci, tandis que la commande après le tube y lit ses données. Tous
les tubes, qu'ils soient anonymes (comme ceux utilisés par le
<EM>shell</EM>) ou nommés (voyez ci-dessous), fonctionnent selon le
principe <EM>FIFO</EM> (<EM>First In, First Out</EM>,
"premier arrivé, premier servi"). Nous avons déjà vu des
exemples sur l'utilisation des tubes avec le <EM>shell</EM>, mais
prenons-en un dans un but d'illustration:

<p><font size="+2"><PRE>
$ ls -d /proc/[0-9] | head -6
/proc/1/
/proc/2/
/proc/3/
/proc/4/
/proc/5/
</PRE></font>

<p>Une chose que vous ne remarquez pas dans cet exemple (parce que cela se
passe trop vite) est que les écritures sur le tube sont bloquantes. Cela
veut dire que quand la commande <CODE>ls</CODE> écrit dans le tube, elle
est bloquée jusqu'à ce qu'un processus à l'autre bout lise depuis le
tube. Pour visualiser cet effet, vous pouvez créer des tubes nommés,
qui, contrairement aux tubes utilisés par le <EM>shell</EM>, ont des noms
(donc ils sont liés, tandis que les tubes utilisés par le <EM>shell</EM>
ne le sont pas). La commande pour créer de tels tubes est
<CODE>mkfifo</CODE>:

<p><font size="-4"><PRE>
$ mkfifo un_tube
$ ls -il
total 0
    169 prw-rw-r--    1 fg       fg              0 déc 10 14:12 un_tube|
  #
  # Vous pouvez voir que le compteur de liens est 1, et que la sortie
  # montre  que le fichier est un tube ('p').
  #
  # Vous pouvez aussi utiliser ln ici :
  #
$ ln un_tube le_même_tube
$ ls -il
total 0
    169 prw-rw-r--    2 fg       fg              0 déc 10 15:37 un_tube|
    169 prw-rw-r--    2 fg       fg              0 déc 10 15:37 le_même_tube|
$ ls -d /proc/[0-9] &gt;un_tube
  #
  # Le processus est bloqué, comme il n'y a pas de lecteurs à l'autre
  # bout. Tapez C-z pour suspendre le processus...
  #
zsh: 3452 suspended  ls -d /proc/[0-9] &gt; un_tube
  #
  # ...Puis mettez-le en tâche de fond :
  #
$ bg
[1]  + continued  ls -d /proc/[0-9] &gt; un_tube
  #
  # Maintenant lisez depuis le tube...
  #
$ head -6 &lt;le_même_tube
  #
  # ...le processus écrivain se termine :
  #
[1]  + 3452 done       ls -d /proc/[0-9] &gt; un_tube
/proc/1/
/proc/2/
/proc/3/
/proc/4/
/proc/5/
$
</PRE></font>

<p>De la même façon, les lectures sont bloquantes. Si nous exécutons les
commandes ci-dessus dans l'ordre inverse, nous observons que
<CODE>head</CODE> est bloqué, en attendant qu'un processus lui donne
quelque chose à lire:

<p><font size="+1"><PRE>
$ head -6 &lt;un_tube
  #
  # Le processus est bloqué, suspendez-le : C-z
  #
zsh: 741 suspended  head -6 &lt; un_tube
  #
  # Mettez-le en tâche de fond...
  #
$ bg
[1]  + continued  head -6 &lt; un_tube
  #
  # ...Et donnez-lui à manger :)
  #
$ ls -d /proc/[0-9] &gt;le_même_tube
$ /proc/1/
/proc/2/
/proc/3/
/proc/4/
/proc/5/
[1]  + 741 done       head -6 &lt; un_tube
$
</PRE></font>

<p>Vous pouvez aussi voir un effet indésirable dans cet exemple: la
commande <CODE>ls</CODE> a fini son exécution avant que la commande
<CODE>head</CODE> prenne le relais. La conséquence est que vous êtes
retourné(e) au prompt immédiatement, mais <CODE>head</CODE> ne s'est
exécuté qu'après. Donc il a effectué sa sortie seulement après que vous
ayez récupéré le prompt <CODE>:)</CODE>


<H1><a name="132">Les fichiers «&nbsp;spéciaux&nbsp;»: fichiers en mode bloc et caractère</a></H1>

<p>Comme il a déjà été dit, de tels fichiers sont soit des fichiers créés
par le système, soit bien des périphériques de votre machine. Nous avons
aussi mentionné que le contenu des fichiers en mode bloc était gardé en
mémoire alors que tel n'était pas le cas des fichiers en mode caractère.
Pour illustrer ceci, insérez une disquette quelconque dans le lecteur et
tapez la commande suivante deux fois de suite:

<p><font size="+2"><PRE>
$ dd if=/dev/fd0 of=/dev/null
</PRE></font>

<p>Vous pouvez observer la chose suivante: tandis que, la première fois que
la commande a été lancée, tout le contenu de la disquette a été lu, la
deuxième fois il n'y a eu aucun accès au lecteur de disquette. C'est
simplement parce que le contenu de la disquette a été gardé en mémoire
quand vous avez lancé la commande la première fois --- et que
vous n'avez pas changé de disquette entre temps.

<p>Mais maintenant, si vous voulez imprimer un gros fichier de cette façon
(si, ça fonctionne):

<p><font size="-2"><PRE>
$ cat /un/gros/fichier/imprimable/quelque/part &gt;/dev/lp0
</PRE></font>

<p>la commande prendra autant de temps que vous la tapiez une, deux ou
cinquante fois. Ceci est dû au fait que <CODE>/dev/lp0</CODE> est un fichier
en mode caractère, et son contenu n'est pas gardé en mémoire.

<p>Le fait que le contenu des fichiers en mode bloc soit gardé en mémoire a
un effet de bord agréable: non seulement les lectures sont gardées en
mémoire, mais c'est aussi le cas des écritures. Cela autorise les
écritures sur disque à être asynchrones: quand vous écrivez un fichier
sur disque, l'opération d'écriture elle-même ne sera pas faite
immédiatement. Elle n'aura lieu que quand <STRONG>Linux</STRONG> le décidera.

<p>Enfin, chacun de ces fichiers spéciaux possède un numéro <STRONG>majeur</STRONG>
et un numéro <STRONG>mineur</STRONG>. Sur la sortie d'un <CODE>ls -l</CODE>, ils
apparaissent en lieu et place de la taille, étant donné que la taille
pour de tels fichiers est hors de propos:

<p><font size="-3"><PRE>
$ ls -l /dev/hda /dev/lp0
brw-rw----    1 root     disk       3,   0 mai  5  1998 /dev/hda
crw-rw----    1 root     daemon     6,   0 mai  5  1998 /dev/lp0
</PRE></font>

<p>Ici, les numéros majeur et mineur de <CODE>/dev/hda</CODE> sont respectivement
3 et 0, tandis que ce sont respectivement 6 et 0 pour <CODE>/dev/lp0</CODE>.
Notez que ces numéros sont uniques par catégorie de fichier, ce qui veut
dire qu'il peut exister un fichier en mode caractère ayant 3 pour majeur
et 0 pour mineur (un tel fichier existe : c'est <CODE>/dev/ttyp0</CODE>), et
de la même façon il peut y avoir un fichier en mode bloc ayant 6 pour
majeur et 0 pour mineur. Ces nombres existent pour une raison bien
simple: cela permet à <STRONG>Linux</STRONG> d'associer les bonnes opérations aux
fichiers (donc aux péripériques auxquels ces fichiers se réfèrent). On
ne contrôle pas un lecteur de disquettes de la même façon que, par
exemple, un disque dur <EM>SCSI</EM>.


<H1><a name="133">Les liens symboliques et la limitation des liens «&nbsp;en dur&nbsp;»</a></H1>

<p>Ici nous avons à faire face à une incompréhension très courante, même
parmi les utilisateurs d'<STRONG>Unix</STRONG>, qui est principalement due au
fait que les liens tels que nous les avons vus jusque là (faussement
appelés liens «&nbsp;en dur&nbsp;») sont seulement associés aux fichiers
réguliers (et nous avons vu que ce n'est pas le cas --- même les
liens symboliques sont «&nbsp;liés&nbsp;»). Mais cela requiert que nous
expliquions d'abord ce que sont les liens symboliques<a name="bodynote16" href="026.html#note16">[16]</a>.

<p>Les liens symboliques sont des fichiers d'un type particulier dont le
seul contenu est une chaîne de caractères arbitraire, qui peut ou non
pointer sur un vrai nom de fichier. Quand vous mentionnez un lien
symbolique sur la ligne de commande ou dans un programme, vous accédez
en fait au fichier sur lequel pointe le lien, s'il existe. Par exemple:

<p><font size="-4"><PRE>
$ echo Bonjour &gt;monfichier
$ ln -s monfichier monlien
$ ls -il
total 4
    169 -rw-rw-r--    1 fg       fg              6 déc 10 21:30 monfichier
    416 lrwxrwxrwx    1 fg       fg              6 déc 10 21:30 monlien -&gt; monfichier
$ cat monfichier
Bonjour
$ cat monlien
Bonjour
</PRE></font>

<p>Vous pouvez voir que le type du fichier <CODE>monlien</CODE> est
<CODE>'l'</CODE>. Les droits d'accès pour un lien symbolique n'ont aucune
signification: ils seront toujours <CODE>rwxrwxrwx</CODE>. Vous pouvez
également voir que c'est un fichier différent de <CODE>monfichier</CODE>,
parce que son numéro d'i-noeud est différent. Mais il se réfère au
fichier <CODE>monfichier</CODE> de façon symbolique, donc quand vous tapez
<CODE>cat monlien</CODE>, vous affichez en fait le contenu du fichier
<CODE>monfichier</CODE>. Pour démontrer qu'un lien symbolique contient une
chaîne arbitraire, nous pouvons faire la chose suivante:

<p><font size="-4"><PRE>
$ ln -s "Je n'existe pas" unautrelien
$ ls -il unautrelien
    747 lrwxrwxrwx    1 fg       fg             15 déc 15 18:01 unautrelien -&gt; Je n'existe pas
$ cat unautrelien
cat: unautrelien: Aucun fichier ou répertoire de ce type
$
</PRE></font>

<p>Mais les liens symboliques existent parce qu'ils s'affranchissent de
plusieurs limitations des liens normaux:


<ul><li>on ne peut pas lier deux fichiers si ceux-ci sont sur des systèmes
de fichiers différents, et pour une raison bien simple: le compteur de
liens est stocké dans l'i-noeud lui-même, et les i-noeuds ne
peuvent pas être partagés par plusieurs systèmes de fichiers. Les liens
symboliques l'autorisent;
<li>on ne peut pas lier deux répertoires, car nous avons vu que le
compteur de liens pour un répertoire a un usage particulier. Mais on peut
faire pointer un lien symbolique sur un répertoire et l'utiliser comme
si c'était vraiment un répertoire.</ul>

<p>Donc les liens symboliques sont très utiles dans plusieurs cas, et très
souvent, les gens tendent à les utiliser pour lier des fichiers même
quand un lien normal est possible. Un avantage des liens normaux,
pourtant, est que vous ne perdez pas le fichier si vous effacez
l'«&nbsp;original&nbsp;» <CODE>:)</CODE>

<p>Enfin, si vous avez observé attentivement, vous savez à quoi correspond
la taille d'un lien symbolique: c'est tout simplement la taille de la
chaîne de caractères.


<H1><a name="134">Les attributs des fichiers</a></H1>

<p>De même que la <EM>FAT</EM> a des attributs de fichiers (archive, fichier
système, invisible), <STRONG>ext2fs</STRONG> a aussi les siens propres, mais ils
sont différents. Non en parlons pour être complet, mais ils sont très
peu utilisés. Toutefois, si vous voulez un système vraiment sécurisé,
continuez la lecture.

<p>Il existe deux commandes pour manipuler les attributs: ce sont
<CODE>lsattr(1)</CODE> et <CODE>chattr(1)</CODE>. Vous l'aurez deviné,
<CODE>lsattr</CODE> <EM>LiSte</EM> les attributs, et
<CODE>chattr</CODE> les <EM>CHange</EM>.  Ces attributs
s'appliquent seulement aux répertoires et aux fichiers réguliers. Ce
sont les suivants:


<ul><li><STRONG><CODE>A</CODE> (<EM>no <u>A</u>ccess time</EM>,
«&nbsp;pas de date d'accès&nbsp;»)</STRONG>:  Si un fichier ou un répertoire a cet
attribut positionné, quand on y accédera, que ce soit en lecture ou en
écriture, sa date de dernier accès ne sera pas mise à jour. Cela peut
être utile, par exemple, sur des fichiers ou répertoires qui sont très
souvent accédés en lecture, en particulier parce que ce paramètre est le
seul à changer sur un i-noeud quand celui-ci est ouvert en lecture
seule.
<li><STRONG><CODE>a</CODE> (<EM><u>a</u>ppend only</EM>,
«&nbsp;uniquement pour ajout&nbsp;»)</STRONG>:   Si un fichier a cet attribut
positionné et est ouvert en écriture, la seule opération possible sera
d'ajouter des données à la fin du fichier. Pour un répertoire, cela
signifie que vous pouvez seulement y ajouter des fichiers, mais vous ne
pouvez ni renommer des fichiers déjà existants ni en effacer. Seul
<CODE>root</CODE> peut positionner ou enlever cet attribut.
<li><STRONG><CODE>d</CODE> (<EM>no <u>d</u>ump</EM>,
«&nbsp;pas de sauvegarde&nbsp;»)</STRONG>:  <CODE>dump(8)</CODE> est
l'utilitaire <STRONG>Unix</STRONG> standard pour faire des sauvegardes. Il
sauvegarde tout système de fichiers pour lequel le compteur de
sauvegarde est à 1 dans <CODE>/etc/fstab</CODE> (voyez le
chapitre&nbsp;33.0). Mais si un fichier ou répertoire a
cet attribut positionné, contrairement aux autres, il ne sera pas pris
en compte lors d'une sauvegarde. Notez que pour les répertoires, cela
inclut également tous les sous-répertoires et fichiers en-dessous de
celui-ci.
<li><STRONG><CODE>i</CODE> (<EM><u>i</u>mmutable</EM>,
«&nbsp;immuable&nbsp;»)</STRONG>:  Un fichier ou répertoire avec cet attribut
ne peut tout simplement pas être modifié: il ne peut pas être renommé,
on ne peut y ajouter aucun lien<a name="bodynote17" href="026.html#note17">[17]</a>, et on ne peut pas l'effacer. Seul <CODE>root</CODE>
peut positionner ou enlever cet attribut. Notez que cela empêche
également les changements à la date de dernier accès, donc vous n'avez
pas besoin de positionner l'attribut <CODE>A</CODE> quand cet attribut-ci
est positionné.
<li><STRONG><CODE>s</CODE> (<EM><u>s</u>ecure deletion</EM>,
«&nbsp;sécurité pour l'action d'effacer&nbsp;»)</STRONG>:  Quand un fichier ou
un répertoire avec cet attribut est effacé, les blocs qu'il occupait sur
disque sont remplis de zéros.
<li><STRONG><CODE>S</CODE> (<EM><u>S</u>ynchronous mode</EM>,
«&nbsp;mode synchrone&nbsp;»)</STRONG>:  Quand un fichier ou répertoire a cet
attribut positionné, toutes les modifications qui y sont apportées sont
synchrones et écrites immédiatement sur disque.</ul>

<p>Vous pouvez, par exemple, placer l'attribut <CODE>'i'</CODE> sur des
fichiers système essentiels pour éviter les mauvaises surprises.  Pensez
aussi à l'attribut <CODE>'A'</CODE> pour les pages de manuel par exemple:
cela évitera beaucoup d'activité disque, et, en particulier, cela
prolongera la durée de vie de la batterie sur les portables.
<hr><a href="015.html">Suivant&nbsp;: Le système de fichiers <CODE>/proc</CODE></a><br><a href="013.html">Précédent&nbsp;: Organisation de l'arborescence des fichiers</a><br><a href="../">Retour</a><br><hr>Copyright © 2000 <a href="http://www.mandrakesoft.com/">MandrakeSoft</a></BODY></HTML>



See more files for this project here

Gulus

Groupe d\'Utilisateurs de Linux de l\'Universit? de Sherbrooke. http://www.gulus.org/

Project homepage: http://sourceforge.net/projects/gulus
Programming language(s): PHP,Shell Script
License: other

  images/
    LMDK520x200.gif
    aftermount.gif
    beforemount.gif
    console2.gif
    emacs_1.gif
    emacs_2.gif
    emacs_3.gif
    kde_app_add.gif
    kde_app_app.gif
    kde_app_exec.gif
    kde_apps_list.gif
    kde_controlcenter.gif
    kde_desk.gif
    kde_desk_conf1.gif
    kde_disknav.gif
    kde_menu_K.gif
    kde_mime_edit.gif
    kde_mime_edit2.gif
    kde_mime_jpeg.gif
    kde_mimetypelist.gif
    kde_openwith.gif
    kde_openwith_sample.gif
    kde_pager.gif
    kde_screensavercfg.gif
    kde_stylecfg.gif
    kdm2.gif
    kfm_ftp.gif
    kfm_icon_home.gif
    kfm_menu_display.gif
    kfm_navig_conf.gif
    kfm_sample_window.gif
    kfm_url_http.gif
    kfm_web.gif
    konsole.gif
    kpackage_all.gif
    kpackage_info.gif
    kppp_compte.gif
    kppp_main.gif
    kppp_start.gif
    lothar.gif
    lothar_ethercfg.gif
    lothar_sndcfg.gif
    netconf_ppp.gif
    passwd_err.gif
    reseau.gif
    samba_swat.gif
    samba_swat_auth.gif
    tinst_authconf.gif
    tinst_bootdsk.gif
    tinst_fmt_ext2.gif
    tinst_fmt_swap.gif
    tinst_hd_dummy.gif
    tinst_hd_mnt.gif
    tinst_hd_slash.gif
    tinst_insclass.gif
    tinst_intro.gif
    tinst_iou.gif
    tinst_keyb.gif
    tinst_lang.gif
    tinst_lilo.gif
    tinst_lilo_options.gif
    tinst_media.gif
    tinst_mouse_detect.gif
    tinst_mouse_type.gif
    tinst_net_ipdns.gif
    tinst_net_ipstatic.gif
    tinst_net_iptype.gif
    tinst_pack_indiv.gif
    tinst_packs.gif
    tinst_pre.gif
    tinst_printer.gif
    tinst_rootpass.gif
    tinst_scsi.gif
    tinst_scsi_pilot.gif
    tinst_services.gif
    tinst_timezone.gif
    tinst_useradd.gif
    tinst_x_monitor.gif
    top.gif
    user_add.gif
    userconf.gif
    vi_1.gif
    vi_2.gif
    vi_3.gif
    xkill.gif
  000.html
  001.html
  002.html
  003.html
  004.html
  005.html
  006.html
  007.html
  008.html
  009.html
  010.html
  011.html
  012.html
  013.html
  014.html
  015.html
  016.html
  017.html
  018.html
  019.html
  020.html
  021.html
  022.html
  023.html
  024.html
  025.html
  026.html
  index.html