1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.
Mais alors dans ça :
$ stat /
File: «/»
Size: 4096 Blocks: 8 IO Block: 4096 répertoire
Device: 801h/2049d Inode: 2 Links: 22
Que signifie exactement "Links 22" ? Empiriquement, j'ai constaté que ça
correspondait aux nombres de dossiers contenus dans "/" (si on compte
les dossiers . et .. aussi). Mais alors pourquoi appeler ça "Links" ?
# dumpe2fs -h /dev/sdb1 | grep 'Block size'
dumpe2fs 1.41.11 (14-Mar-2010)
Block size: 4096
# sfdisk -l -uB /dev/sdb
Disque /dev/sdb : 19457 cylindres, 255 têtes, 63 secteurs/piste
Unités= blocs de 1024 octets, décompte à partir de 0
qui m'incite à penser qu'un bloc fait 1024 octet. Il me semble bien que
la réponse est bien 4096 octet (d'après google). Alors que représente ce
1024 octet exactement ?
1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.
Mais alors dans ça :
$ stat /
File: «/»
Size: 4096 Blocks: 8 IO Block: 4096 répertoire
Device: 801h/2049d Inode: 2 Links: 22
Que signifie exactement "Links 22" ? Empiriquement, j'ai constaté que ça
correspondait aux nombres de dossiers contenus dans "/" (si on compte
les dossiers . et .. aussi). Mais alors pourquoi appeler ça "Links" ?
# dumpe2fs -h /dev/sdb1 | grep 'Block size'
dumpe2fs 1.41.11 (14-Mar-2010)
Block size: 4096
# sfdisk -l -uB /dev/sdb
Disque /dev/sdb : 19457 cylindres, 255 têtes, 63 secteurs/piste
Unités= blocs de 1024 octets, décompte à partir de 0
qui m'incite à penser qu'un bloc fait 1024 octet. Il me semble bien que
la réponse est bien 4096 octet (d'après google). Alors que représente ce
1024 octet exactement ?
1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.
Mais alors dans ça :
$ stat /
File: «/»
Size: 4096 Blocks: 8 IO Block: 4096 répertoire
Device: 801h/2049d Inode: 2 Links: 22
Que signifie exactement "Links 22" ? Empiriquement, j'ai constaté que ça
correspondait aux nombres de dossiers contenus dans "/" (si on compte
les dossiers . et .. aussi). Mais alors pourquoi appeler ça "Links" ?
# dumpe2fs -h /dev/sdb1 | grep 'Block size'
dumpe2fs 1.41.11 (14-Mar-2010)
Block size: 4096
# sfdisk -l -uB /dev/sdb
Disque /dev/sdb : 19457 cylindres, 255 têtes, 63 secteurs/piste
Unités= blocs de 1024 octets, décompte à partir de 0
qui m'incite à penser qu'un bloc fait 1024 octet. Il me semble bien que
la réponse est bien 4096 octet (d'après google). Alors que représente ce
1024 octet exactement ?
1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.
Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.
Que signifie exactement "Links 22" ? Empiriquement, j'ai constaté que ça
correspondait aux nombres de dossiers contenus dans "/" (si on compte
les dossiers . et .. aussi). Mais alors pourquoi appeler ça "Links" ?
Parce que c'en est.
Un pour le lien depuis le répertoire parent, un pour
le "." depuis le répertoire lui-même et un pour le ".." dans chaque
répertoire fils.
4096 est la taille d'un bloc du système de fichiers ext2/3/4 qui est sur
sdb1.
1024 est une taille de bloc arbitraire utilisée par sfdisk pour
l'affichage.
La taille d'un secteur "visible" du disque sdb est
probablement 512 octets, comme sur la plupart des disques actuels. On
commence à voir des disques avec des secteurs physiques de 4096 octets,
mais la taille visible reste 512 par compatibilité.
1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.
Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.
Que signifie exactement "Links 22" ? Empiriquement, j'ai constaté que ça
correspondait aux nombres de dossiers contenus dans "/" (si on compte
les dossiers . et .. aussi). Mais alors pourquoi appeler ça "Links" ?
Parce que c'en est.
Un pour le lien depuis le répertoire parent, un pour
le "." depuis le répertoire lui-même et un pour le ".." dans chaque
répertoire fils.
4096 est la taille d'un bloc du système de fichiers ext2/3/4 qui est sur
sdb1.
1024 est une taille de bloc arbitraire utilisée par sfdisk pour
l'affichage.
La taille d'un secteur "visible" du disque sdb est
probablement 512 octets, comme sur la plupart des disques actuels. On
commence à voir des disques avec des secteurs physiques de 4096 octets,
mais la taille visible reste 512 par compatibilité.
1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.
Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.
Que signifie exactement "Links 22" ? Empiriquement, j'ai constaté que ça
correspondait aux nombres de dossiers contenus dans "/" (si on compte
les dossiers . et .. aussi). Mais alors pourquoi appeler ça "Links" ?
Parce que c'en est.
Un pour le lien depuis le répertoire parent, un pour
le "." depuis le répertoire lui-même et un pour le ".." dans chaque
répertoire fils.
4096 est la taille d'un bloc du système de fichiers ext2/3/4 qui est sur
sdb1.
1024 est une taille de bloc arbitraire utilisée par sfdisk pour
l'affichage.
La taille d'un secteur "visible" du disque sdb est
probablement 512 octets, comme sur la plupart des disques actuels. On
commence à voir des disques avec des secteurs physiques de 4096 octets,
mais la taille visible reste 512 par compatibilité.
Le 01/11/2010 17:54, Pascal Hambourg a écrit :1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.
Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.
Ah, mais alors est-ce que tu as un exemple reproductible à me proposer ?
Personnellement, j'ai essayé ça :
$ mkdir dossierPipeau
$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire
Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.
Un pour le lien depuis le répertoire parent, un pour
le "." depuis le répertoire lui-même et un pour le ".." dans chaque
répertoire fils.
Je si comprends bien :
* un fichier (et/ou dossier) est caractérisé de manière unique par son
numéro d'i-node.
* un dossier est un petit fichier dont le contenu peut se voir une sorte
de tableau où les entrées sont de la forme (numéro d'i-node ; nom), un
peu comme ce que retourne la commande "ls -1ia mon_dossier".
* un lien direct vers un fichier (et/ou dossier) d'i-node N est un
entrée (un couple) dans un dossier de la forme (N ; xxx)
Et vu ainsi, avec le décompte que tu me donnes, ça colle. :-)
Je ne sais pas si c'est une coïncidence heureuse et volontaire, mais il
s'avère que ça donne au final le nombre de sous-dossiers contenus dans
le dossier (en comptant . et .. aussi).
Le 01/11/2010 17:54, Pascal Hambourg a écrit :
1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.
Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.
Ah, mais alors est-ce que tu as un exemple reproductible à me proposer ?
Personnellement, j'ai essayé ça :
$ mkdir dossierPipeau
$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire
Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.
Un pour le lien depuis le répertoire parent, un pour
le "." depuis le répertoire lui-même et un pour le ".." dans chaque
répertoire fils.
Je si comprends bien :
* un fichier (et/ou dossier) est caractérisé de manière unique par son
numéro d'i-node.
* un dossier est un petit fichier dont le contenu peut se voir une sorte
de tableau où les entrées sont de la forme (numéro d'i-node ; nom), un
peu comme ce que retourne la commande "ls -1ia mon_dossier".
* un lien direct vers un fichier (et/ou dossier) d'i-node N est un
entrée (un couple) dans un dossier de la forme (N ; xxx)
Et vu ainsi, avec le décompte que tu me donnes, ça colle. :-)
Je ne sais pas si c'est une coïncidence heureuse et volontaire, mais il
s'avère que ça donne au final le nombre de sous-dossiers contenus dans
le dossier (en comptant . et .. aussi).
Le 01/11/2010 17:54, Pascal Hambourg a écrit :1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.
Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.
Ah, mais alors est-ce que tu as un exemple reproductible à me proposer ?
Personnellement, j'ai essayé ça :
$ mkdir dossierPipeau
$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire
Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.
Un pour le lien depuis le répertoire parent, un pour
le "." depuis le répertoire lui-même et un pour le ".." dans chaque
répertoire fils.
Je si comprends bien :
* un fichier (et/ou dossier) est caractérisé de manière unique par son
numéro d'i-node.
* un dossier est un petit fichier dont le contenu peut se voir une sorte
de tableau où les entrées sont de la forme (numéro d'i-node ; nom), un
peu comme ce que retourne la commande "ls -1ia mon_dossier".
* un lien direct vers un fichier (et/ou dossier) d'i-node N est un
entrée (un couple) dans un dossier de la forme (N ; xxx)
Et vu ainsi, avec le décompte que tu me donnes, ça colle. :-)
Je ne sais pas si c'est une coïncidence heureuse et volontaire, mais il
s'avère que ça donne au final le nombre de sous-dossiers contenus dans
le dossier (en comptant . et .. aussi).
Francois Lafont a écrit :Le 01/11/2010 17:54, Pascal Hambourg a écrit :1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.
Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.
Ah, mais alors est-ce que tu as un exemple reproductible à me proposer ?
Inutile, tu l'as déjà fait ci-dessous.Personnellement, j'ai essayé ça :
$ mkdir dossierPipeau
Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire
Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.
C'est ce que j'entendais par "n'importe comment". En gros, autrement que
par la création d'un répertoire. La page de manuel de la commande ln
mentionne l'option -d, -F, --directory pour permettre au
super-utilisateur de créer des liens vers des répertoire, mais signale
que cela va probablement échouer à cause de restrictions du système.
La commande "ln" de debugfs (pour un système de fichiers ext2/3 et
peut-être 4) permet peut-être d'outrepasser cette limitation, mais c'est
à ses risques et périls.
Francois Lafont a écrit :
Le 01/11/2010 17:54, Pascal Hambourg a écrit :
1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.
Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.
Ah, mais alors est-ce que tu as un exemple reproductible à me proposer ?
Inutile, tu l'as déjà fait ci-dessous.
Personnellement, j'ai essayé ça :
$ mkdir dossierPipeau
Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.
$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire
Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.
C'est ce que j'entendais par "n'importe comment". En gros, autrement que
par la création d'un répertoire. La page de manuel de la commande ln
mentionne l'option -d, -F, --directory pour permettre au
super-utilisateur de créer des liens vers des répertoire, mais signale
que cela va probablement échouer à cause de restrictions du système.
La commande "ln" de debugfs (pour un système de fichiers ext2/3 et
peut-être 4) permet peut-être d'outrepasser cette limitation, mais c'est
à ses risques et périls.
Francois Lafont a écrit :Le 01/11/2010 17:54, Pascal Hambourg a écrit :1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.
Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.
Ah, mais alors est-ce que tu as un exemple reproductible à me proposer ?
Inutile, tu l'as déjà fait ci-dessous.Personnellement, j'ai essayé ça :
$ mkdir dossierPipeau
Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire
Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.
C'est ce que j'entendais par "n'importe comment". En gros, autrement que
par la création d'un répertoire. La page de manuel de la commande ln
mentionne l'option -d, -F, --directory pour permettre au
super-utilisateur de créer des liens vers des répertoire, mais signale
que cela va probablement échouer à cause de restrictions du système.
La commande "ln" de debugfs (pour un système de fichiers ext2/3 et
peut-être 4) permet peut-être d'outrepasser cette limitation, mais c'est
à ses risques et périls.
$ mkdir dossierPipeau
Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.
$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire
Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.
C'est ce que j'entendais par "n'importe comment". En gros, autrement que
par la création d'un répertoire. La page de manuel de la commande ln
mentionne l'option -d, -F, --directory pour permettre au
super-utilisateur de créer des liens vers des répertoire, mais signale
que cela va probablement échouer à cause de restrictions du système.
La commande "ln" de debugfs (pour un système de fichiers ext2/3 et
peut-être 4) permet peut-être d'outrepasser cette limitation, mais c'est
à ses risques et périls.
* un fichier (et/ou dossier) est caractérisé de manière unique par son
numéro d'i-node.
Oui, du moins dans un même système de fichiers.
* un lien direct vers un fichier (et/ou dossier) d'i-node N est un
entrée (un couple) dans un dossier de la forme (N ; xxx)
Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé.
$ mkdir dossierPipeau
Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.
$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire
Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.
C'est ce que j'entendais par "n'importe comment". En gros, autrement que
par la création d'un répertoire. La page de manuel de la commande ln
mentionne l'option -d, -F, --directory pour permettre au
super-utilisateur de créer des liens vers des répertoire, mais signale
que cela va probablement échouer à cause de restrictions du système.
La commande "ln" de debugfs (pour un système de fichiers ext2/3 et
peut-être 4) permet peut-être d'outrepasser cette limitation, mais c'est
à ses risques et périls.
* un fichier (et/ou dossier) est caractérisé de manière unique par son
numéro d'i-node.
Oui, du moins dans un même système de fichiers.
* un lien direct vers un fichier (et/ou dossier) d'i-node N est un
entrée (un couple) dans un dossier de la forme (N ; xxx)
Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé.
$ mkdir dossierPipeau
Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.
$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire
Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.
C'est ce que j'entendais par "n'importe comment". En gros, autrement que
par la création d'un répertoire. La page de manuel de la commande ln
mentionne l'option -d, -F, --directory pour permettre au
super-utilisateur de créer des liens vers des répertoire, mais signale
que cela va probablement échouer à cause de restrictions du système.
La commande "ln" de debugfs (pour un système de fichiers ext2/3 et
peut-être 4) permet peut-être d'outrepasser cette limitation, mais c'est
à ses risques et périls.
* un fichier (et/ou dossier) est caractérisé de manière unique par son
numéro d'i-node.
Oui, du moins dans un même système de fichiers.
* un lien direct vers un fichier (et/ou dossier) d'i-node N est un
entrée (un couple) dans un dossier de la forme (N ; xxx)
Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé.
Le 02/11/2010 10:05, Pascal Hambourg a écrit :$ mkdir dossierPipeau
Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.
Ok, par contre c'est "deux liens" que tu voulais dire je suppose (si 58
est le numéro inode de dossierPipeau/, on a l'entrée (58 ;
dossierPipeau) contenue dans le dossier parent de dossierPipeau/ et
l'entrée (58 ; . ) dans dossierPipeau/ lui-même).
Ok. En même temps, c'est si grave d'avoir une boucle infinie ?
Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé.
Et pour les fichiers de type "dossier", le mécanisme est un peu
différent, non ? Car un dossier ne peut être supprimé que s'il est vide
et pourtant même vide il y a deux liens pointant vers lui.
Le 02/11/2010 10:05, Pascal Hambourg a écrit :
$ mkdir dossierPipeau
Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.
Ok, par contre c'est "deux liens" que tu voulais dire je suppose (si 58
est le numéro inode de dossierPipeau/, on a l'entrée (58 ;
dossierPipeau) contenue dans le dossier parent de dossierPipeau/ et
l'entrée (58 ; . ) dans dossierPipeau/ lui-même).
Ok. En même temps, c'est si grave d'avoir une boucle infinie ?
Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé.
Et pour les fichiers de type "dossier", le mécanisme est un peu
différent, non ? Car un dossier ne peut être supprimé que s'il est vide
et pourtant même vide il y a deux liens pointant vers lui.
Le 02/11/2010 10:05, Pascal Hambourg a écrit :$ mkdir dossierPipeau
Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.
Ok, par contre c'est "deux liens" que tu voulais dire je suppose (si 58
est le numéro inode de dossierPipeau/, on a l'entrée (58 ;
dossierPipeau) contenue dans le dossier parent de dossierPipeau/ et
l'entrée (58 ; . ) dans dossierPipeau/ lui-même).
Ok. En même temps, c'est si grave d'avoir une boucle infinie ?
Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé.
Et pour les fichiers de type "dossier", le mécanisme est un peu
différent, non ? Car un dossier ne peut être supprimé que s'il est vide
et pourtant même vide il y a deux liens pointant vers lui.
$ mkdir dossierPipeau
Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.
Ok, par contre c'est "deux liens" que tu voulais dire je suppose (si 58
est le numéro inode de dossierPipeau/, on a l'entrée (58 ;
dossierPipeau) contenue dans le dossier parent de dossierPipeau/ et
l'entrée (58 ; . ) dans dossierPipeau/ lui-même).
Et ".." dans dossierPipeau/ pointant vers le répertoire parent.
Ok. En même temps, c'est si grave d'avoir une boucle infinie ?
J'ai tendance à penser que oui, si elle n'est pas détectée. Et j'imagine
que le fait que la structure de répertoires ne soit plus purement
arborescente mais contiennent des boucles ou des "ponts" entre deux
branches peut poser des problèmes conceptuels (quid d'un chroot dans ces
conditions).
Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé.
Et pour les fichiers de type "dossier", le mécanisme est un peu
différent, non ? Car un dossier ne peut être supprimé que s'il est vide
et pourtant même vide il y a deux liens pointant vers lui.
C'est pour cela qu'il y a une fonction différente, rmdir(2).
$ mkdir dossierPipeau
Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.
Ok, par contre c'est "deux liens" que tu voulais dire je suppose (si 58
est le numéro inode de dossierPipeau/, on a l'entrée (58 ;
dossierPipeau) contenue dans le dossier parent de dossierPipeau/ et
l'entrée (58 ; . ) dans dossierPipeau/ lui-même).
Et ".." dans dossierPipeau/ pointant vers le répertoire parent.
Ok. En même temps, c'est si grave d'avoir une boucle infinie ?
J'ai tendance à penser que oui, si elle n'est pas détectée. Et j'imagine
que le fait que la structure de répertoires ne soit plus purement
arborescente mais contiennent des boucles ou des "ponts" entre deux
branches peut poser des problèmes conceptuels (quid d'un chroot dans ces
conditions).
Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé.
Et pour les fichiers de type "dossier", le mécanisme est un peu
différent, non ? Car un dossier ne peut être supprimé que s'il est vide
et pourtant même vide il y a deux liens pointant vers lui.
C'est pour cela qu'il y a une fonction différente, rmdir(2).
$ mkdir dossierPipeau
Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.
Ok, par contre c'est "deux liens" que tu voulais dire je suppose (si 58
est le numéro inode de dossierPipeau/, on a l'entrée (58 ;
dossierPipeau) contenue dans le dossier parent de dossierPipeau/ et
l'entrée (58 ; . ) dans dossierPipeau/ lui-même).
Et ".." dans dossierPipeau/ pointant vers le répertoire parent.
Ok. En même temps, c'est si grave d'avoir une boucle infinie ?
J'ai tendance à penser que oui, si elle n'est pas détectée. Et j'imagine
que le fait que la structure de répertoires ne soit plus purement
arborescente mais contiennent des boucles ou des "ponts" entre deux
branches peut poser des problèmes conceptuels (quid d'un chroot dans ces
conditions).
Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé.
Et pour les fichiers de type "dossier", le mécanisme est un peu
différent, non ? Car un dossier ne peut être supprimé que s'il est vide
et pourtant même vide il y a deux liens pointant vers lui.
C'est pour cela qu'il y a une fonction différente, rmdir(2).