Discussion :

[zephyre]

Bonjour,

J'ai cherché dans le man ls avec l'option -a mais je n'ai rien trouvé qui puisse répondre à ma question.
Lorsqu'on fait la commande (dans un répertoire quelconque) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ls -a

Il y a un chiffre qui apparait juste à la droite des droits, voir ci dessous l'image :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[ATTACH=CONFIG]633661[/ATTACH]

Dans cette image, il est clairement dit que ce chiffre indique le nombre de lien.
Je ne comprends pas ce que cela veut dire.
J'ai pas l'impression que cela est un rapport avec le nombre de lien physique ou symbolique du fichier en question, mais peut être je me trompe.
J'aurai besoins de vos lumières pour éclaircir ce sujet.

Merci pour votre aide,
Cordialement.

[Sve@r]

Bonjour

Dans cette image, il est clairement dit que ce chiffre indique le nombre de lien.

Plus exactement c'est "le nombre de noms associés à l'inode".
Commençons par la base: c'est quoi un fichier. Un fichier c'est simplement une structure contenant

• un numéro
• un type et des droits
• une taille
• un propriétaire user et groupe
• un compteur de liens (c'est de lui qu'il s'agit ici)
• des différentes dates (création, mise à jour, accès)
• des datas (son contenu quoi)

On nomme cette structure un "inode" (noeud d'informations). Un fichier c'est donc juste un inode avec un numéro (de 2 à 65535). Et tu remarqueras qu'on ne trouve pas de nom dans cette structure.
Ensuite il y a le dossier qui contient des fichiers (exemple "/etc/passwd" => un nom "passwd" dans le dossier "etc/", ce dossier "etc/" se réduisant de la même façon par un nom "etc" dans le dossier "/").
Intrinsèquement parlant, un dossier ne contient que des lignes, chaque ligne ne contenant que 2 infos

• un nom
• un numéro d'inode

Si tu demandes "affiche le fichier /etc/passwd", le système partira de l'inode n° 2 (tout premier inode du système reliée à "/"), va chercher à l'intérieur de ce dossier le nom"etc" et récupère son numéro d'inode.
Cet inode étant de type "directory" le système recommence alors de ce numéro d'inode là et va chercher, dans ce nouveau dossier, le nom "passwd" et récupère son numéro d'inode.
Cet inode étant de type "fichier", le système l'ouvre, le lit et te l'affiche.

Donc les noms des fichiers se trouvent dans les dossiers et c'est l'association "nom => n° d'inode" faite à chaque étape de l'arborescence qui permet de retrouver au final les datas du fichier demandé.

Ainsi, étant donné qu'un nom n'est qu'une entrée dans un répertoire, entrée associée à un numéro d'inode, rien n'interdit d'avoir un autre nom dans ce même répertoire (ou un autre nom dans un autre répertoire) associé au même numéro d'inode => c'est ce qu'on nomme "les liens" (liens physique par opposition aux liens symboliques qui sont un tout autre concept qui n'a rien à voir).
Et pour que le système s'y retrouve (surtout quand on demande une suppression d'un fichier, c'est à dire enlever son nom du dossier qui le contient), l'inode connait combien de noms lui sont associés. Et à chaque suppression ce compteur se décrémente et s'il tombe à 0 le fichier (l'inode) est alors réellement supprimé du disque.

Et c'est ce compteur que tu vois là.

Et pour les dossiers, ce chiffre montre le nombre de sous-dossiers qu'il contient (nombre toujours au-moins égal à 2 car un dossier contient à minima deux sous-dossiers qui sont "." et "..").

[Jipété]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ls -a

ou ls -al ?

En tout cas chez moi y a pas photo, c'est -al obligatoire.

[zephyre]

Bonjour
Plus exactement c'est "le nombre de noms associés à l'inode".

Donc l'association se fait dans ce sens dans le répertoire courant au niveau du système :
inode ---> nom
ET PAS,
nom ----> inode

Car si j'ai bien compris on peut associer différents noms au MÊME numéro d'inode pour un fichier basique (pas répertoire).
Et quand on a plusieurs noms associés au MÊME inode pour un fichier basique cela s'appelle un lien physique ? O/N
Cette association inode ----> nom se fait dans le dossier courant du fichier en question.

Question :
Si l'inode est codé sur un octet soit max 65 535 (en supposant que l'inode 0 soit réservé à la racine).
Cette inode est forcément unique car elle permet d'identifier au sein du système de manière unique ou est un fichier (fichier au sens large, y compris les répertoires).
ça veut dire qu'on ne peux avoir que max 65 535 fichier (au sens large, y compris les répertoires) sur son système ?
Sinon je ne vois pas comment le système va faire pour repérer les autres fichiers qui seront à l'avenir créer ?

Y a un truc que je ne comprends pas :
Si un fichier n'a pas de nom mais simplement des propriétés et un numéro d'inode alors pourquoi le système m'empêche de faire la chose suivante :
Je suis dans le repertoire = r1 et je veux créer au sein de ce répertoire deux fichiers nommés f1 et f1 (même nom).
Tant qu'ils ont un inode différent il ne devrait pas y avoir de problème ?
Puisque le système ne voit que dans le répertoire courant :
Un nom
Un numéro d'inode
Il suffit juste qu'il ai un inode différent.

[Sve@r]

En tout cas chez moi y a pas photo, c'est -al obligatoire.

Coupons la poire en deux en admettant que ls -l suffira si on ne cherche pas les fichiers cachés (et même fonctionne aussi sur un fichier caché à condition qu'il soit nommé => ls -l .profile fonctionne et affiche les détails de ce fichier)

Donc l'association se fait dans ce sens dans le répertoire courant au niveau du système :
inode ---> nom
ET PAS,
nom ----> inode

Non, c'est nom => inode. Quand le système balaye le dossier "etc" (et je parle bien de "etc" et non pas de "/etc" car dans cette étape le balayage de "/" est maintenant terminé) à la recherche du nom "passwd" et qu'il le trouve, il récupère alors son numéro d'inode puis va taper dans cet inode pour en extraire les datas (relis la structure de l'inode)
Et le fait de partir du répertoire courant c'est uniquement si tu demandes un nom relatif (un nom ne commençant pas par "/"). Dans ce cas effectivement le système commence à chercher ce nom dans le dossier courant. Et effectivement, si tu réfléchis bien, quel que soit un chemin ne commençant pas par "/", alors il se voit effectivement depuis le dossier courant (même un chemin commençant par "." ou ".." car ces deux noms eux-aussi existent dans le dossier courant).

Car si j'ai bien compris on peut associer différents noms au MÊME numéro d'inode pour un fichier basique (pas répertoire).

En fait on "pourrait" aussi associer différents noms à un même inode de répertoire. Il n'y a aucune impossibilité technique. La commande "ln" possède d'ailleurs l'option "-d" permettant cette action mais réservée à root.
Si c'est interdit c'est uniquement pour des raisons de logique. Si tu lies par exemple "/var/log/truc" à "/var" alors comme le système n'a aucun moyen (aucun moyen "léger") de détecter la boucle, une commande récursive (comme ls -R ou find ou chmod -R ou ...) en partant de "/var" bouclerait à l'infini.

Et quand on a plusieurs noms associés au MÊME inode pour un fichier basique cela s'appelle un lien physique ? O/N

Oui

Cette association inode ----> nom se fait dans le dossier courant du fichier en question.

C'est une association nom => inode !!! Et en effet rien n'interdit d'associer 500 noms au même inode

Si l'inode est codé sur un octet soit max 65 535 (en supposant que l'inode 0 soit réservé à la racine).

Alors 65535 c'est pas un mais deux octets. Toutefois c'est le 2 qui est réservé pour la racine. Le 0 étant rarement utilisé pour identifier quelque chose et le 1 étant "réservé" au cas où il serait utile un jour. Donc au final 65534 inodes max (numérotées de 2 à 65535).

Cette inode est forcément unique car elle permet d'identifier au sein du système de manière unique ou est un fichier (fichier au sens large, y compris les répertoires).

Exact. Et on parle bien de tous les types de fichiers dans ces 65534 => fichiers classiques, dossiers, lien symboliques (eux-aussi ont un inode), fichiers pipes, fichiers sockets, fichiers spéciaux bloc et fichiers spéciaux caractères. Chaque fichier créé, quel que soit son type, consomme un numéro sur les 65534 possibles.

ça veut dire qu'on ne peux avoir que max 65 535 fichier (au sens large, y compris les répertoires) sur son système ?

Pas sur son système, seulement sur son filesystem. C'est une nuance qui a son importance. Ce que j'ai décrit tantôt c'était la description d'un filesystem. Deux FS ont chacun cette même implémentation mais chacun a sa propre zone d'inodes (avec 65534 inodes possibles par zone donc par FS) . C'est la raison qui fait qu'on ne peut pas créer de liens entre deux FS différents. Et c'est cette impossibilité qui a amené dans les années 1990 les "liens symboliques" qui se résument comme "fichier contenant le chemin d'un autre fichier".

Sinon je ne vois pas comment le système va faire pour repérer les autres fichiers qui seront à l'avenir créer ?

Ben voilà, par le fait d'avoir plusieurs FS sur son OS. Et accessoirement j'ai décrit le FS Unix mais le FS Linux a évolué et les numéros d'inodes sont maintenant sur 4 octets.

Y a un truc que je ne comprends pas :
Si un fichier n'a pas de nom mais simplement des propriétés et un numéro d'inode alors pourquoi le système m'empêche de faire la chose suivante :
Je suis dans le repertoire = r1 et je veux créer au sein de ce répertoire deux fichiers nommés f1 et f1 (même nom).
Tant qu'ils ont un inode différent il ne devrait pas y avoir de problème ?

Puisque le système ne voit que dans le répertoire courant :
Un nom
Un numéro d'inode
Il suffit juste qu'il ai un inode différent.

Parce que tu vois ça comme une liaison inode => nom alors que c'est une liaison nom => inode.
Et donc si, dans un dossier, un nom permet de faire le lien vers l'inode il devient alors évident que le nom doit-être unique. Si dans un dossier tu as deux noms "f1" et "f1" comment alors ton OS peut savoir quel inode aller taper quand on demande cat f1?

[chrtophe]

ça veut dire qu'on ne peux avoir que max 65 535 fichier (au sens large, y compris les répertoires) sur son système ?

Non car tu as plusieurs niveaux d'indirection. Sous les FS Linux, ce sont les inodes qui contiennent les méta-données d'un fichier comme sa date de modif, création, sa taille, ses droits, etc. Un ou plusieurs noms de fichiers (minimum un) peuvent pointer sur cet inode. En dehors du nom originel, ce seront des liens symboliques.

[Sve@r]

Non car tu as plusieurs niveaux d'indirection. Sous les FS Linux, ce sont les inodes qui contiennent les méta-données d'un fichier comme sa date de modif, création, sa taille, ses droits, etc. Un ou plusieurs noms de fichiers (minimum un) peuvent pointer sur cet inode. En dehors du nom originel, ce seront des liens symboliques.

Sa question portait juste sur le nombre max d'inodes possibles (un numéro allant de 0 à N ne propose que N+1 valeurs possibles).
Juste qu'il pense "nombre max par OS" alors qu'il s'agit de "nombre max par FS".

[Flodelarab]

Bonjour

Un fichier n'est supprimé que quand tous les liens physiques sur l'inode ont disparu. Si tu ne veux pas qu'un fichier cobaye.txt disparaisse dans le dossier ~/mon/dossier/courant/, tu peux créer un lien physique dans le dossier ~/mon/dossier/sauvegarde/. Ainsi, même si l'utilisateur supprime ~/mon/dossier/courant/cobaye.txt, il restera ~/mon/dossier/sauvegarde/cobaye.txt, parfaitement identique, puisque c'est lui-même.

[zephyre]

Merci beaucoup Sve@r.
Ok donc on fait l'association dans ce sens :
nom ---> inode
ET PAS,
inode ---> nom

J'ai tout compris y a juste un truc qui n'est pas tout à fait clair pour moi.
Cela concerne la citation ci-dessous :

En fait on "pourrait" aussi associer différents noms à un même inode de répertoire. Il n'y a aucune impossibilité technique. La commande "ln" possède d'ailleurs l'option "-d" permettant cette action mais réservée à root.
Si c'est interdit c'est uniquement pour des raisons de logique. Si tu lies par exemple "/var/log/truc" à "/var" alors comme le système n'a aucun moyen (aucun moyen "léger") de détecter la boucle, une commande récursive (comme ls -R ou find ou chmod -R ou ...) en partant de "/var" bouclerait à l'infini.

Je résume :
Si tu fais un lien physique de "/var/log/truc" ---> /var
Donc y a un lien physique.
On a dit qu'un lien physique sur un fichier basique c'est donner un nom différent au MÊME inode.
Donc si je reprends tes termes :
On part de la racine = '/'
On cherche le nom = "var"
On identifie son inode
On se place dans cet inode.
On cherche le nom = "log"
On identifie son inode
On se place dans cet inode
On cherche le nom = "truc"
C'est un fichier basique donc on affiche le contenu (data).

Mais ensuite comment ça se passe avec le lien physique ?
Par ce que là c'est un fichier basique ("/var/log/truc") ---> répertoire ("/var")

Moi je pense en gros que :
On arrive au fichier "/var/log/truc"
Il consulte ses noms (c'est précisément cette partie que je n'arrive pas à comprendre car on a dit qu'un fichier basique au niveau de la structure de donnée, inode, n'avait pas de nom ?)
Il pointe vers /var
Et recommence indéfiniment d’où la boucle infini dans une commande récursive telle que ls -R ou find.

[Sve@r]

Je résume :
Si tu fais un lien physique de "/var/log/truc" ---> /var
Donc y a un lien physique.
On a dit qu'un lien physique sur un fichier basique c'est donner un nom différent au MÊME inode.
Donc si je reprends tes termes :
On part de la racine = '/'
On cherche le nom = "var"
On identifie son inode
On se place dans cet inode.
On cherche le nom = "log"
On identifie son inode
On se place dans cet inode
On cherche le nom = "truc"
C'est un fichier basique donc on affiche le contenu (data).

Parfait.
Sauf que dans mon exemple, je faisais un lien physique sur un dossier (dossier /var/log/truc sur le dossier /var). Donc "truc" n'est pas un fichier basique mais un dossier. Et comme il s'agit du dossier "var", dans une commande récursive, le système

• balaye "var" et récupère tous ses dossiers (donc aussi le dossier log). Ensuite il traite tous les dossiers (donc y compris le dossier log)
• balaye "log" et récupère tous ses dossiers (donc aussi le dossier truc). Ensuite il traite tous les dossiers (donc y compris le dossier truc)
• balaye "truc" et récupère tous ses dossiers (donc aussi le dossier log). Ensuite il traite tous les dossiers (donc y compris le dossier log)
• balaye "log" et récupère tous ses dossiers (donc aussi le dossier truc). Ensuite il traite tous les dossiers (donc y compris le dossier truc)
• ...

Mais ensuite comment ça se passe avec le lien physique ?
Par ce que là c'est un fichier basique ("/var/log/truc") ---> répertoire ("/var")

Le type de fichier est inscrit dans l'inode. Le système, en trouvant "truc", va récupérer son inode et là voit qu'il s'agit d'un dossier.

Moi je pense en gros que :
On arrive au fichier "/var/log/truc"
Il consulte ses noms (c'est précisément cette partie que je n'arrive pas à comprendre car on a dit qu'un fichier basique au niveau de la structure de donnée, inode, n'avait pas de nom ?)

Il trouve les noms dans le dossier. De là, les noms lui refont pointer vers l'inode.

Mais bon, on va abandonner l'histoire du lien physique vers un dossier, j'en ai parlé pour montrer pourquoi c'était impossible mais si ça commence à t'embrouiller...
Reprenons du début: cat /etc/passwd:

• lecture de l'inode 2 (premier inode racine d'un FS). C'est un dossier (type=d). Si les droits (stockés aussi dans l'inode) l'autorisent, alors ouverture et lecture des datas au format "dossier" (2 colonnes: nom et inum)
• recherche dans ces datas le nom "etc" (je dis "nom" et pas "dossier" car là, le système ne sait pas encore que "etc" est un dossier). On le trouve ou pas. Si on le trouve pas, message d'erreur et arrêt. Mais on le trouve et il est inum 123
• lecture de l'inode 123. C'est un dossier (type=d). Si les droits de ce dossier là aussi l'autorisent, alors ouverture et lecture des datas au format "dossier" (2 colonnes: nom et inum)
• recherche dans ces datas le nom "passwd". On le trouve ou pas. Si on le trouve pas, message d'erreur et arrêt. Mais on le trouve et il est inum 456
• lecture de l'inode 456. C'est un fichier (type=-). Si les droits de ce fichier là encore l'autorisent, alors ouverture et lecture des datas (qui sont, cette fois, du point de vue de l'OS, du texte brut) et affichage à l'écran de ce texte (texte, qui, pour toi, correspond à des infos intelligibles)

Si maintenant on crée un lien ln /etc/passwd /etc/truc/toto (tu remplaceras "truc" par n'importe quel ssous-dossier de "/etc" de ta machine) alors le nom "toto" dans le dossier "truc" a aussi l'inode 456. Donc une action cat /etc/truc/toto aura le même déroulé (sauf qu'il y a une étape supplémentaire pour lire dossier supplémentaire "truc").

Tu peux voir les numéros d'inode via l'option "-i" de la commande ls.

[zephyre]

J'ai tout compris.
C'est clair pour moi.
Il fallait simplement préciser que :
/var/log/truc est un dossier et NON un fichier basique.
Ainsi moi je l'aurai plutôt écrit :
/var/log/truc/ (avec un slash à la fin pour préciser qu'il s'agit d'un dossier sinon je ne peux pas deviner)


Je testerai les commandes que tu m'as donné sve@r ce week-end.
Je vais laisser le sujet ouvert jusque là.
Merci encore sve@r !

[Sve@r]

sinon je ne peux pas deviner)

Quand j'ai écrit...

Si tu lies par exemple "/var/log/truc" à "/var"

... c'était pour illustrer mon expérience de pensée sur la possibilité de lier un nom sur un inode de répertoire. Là déjà il y avait intuitivement quelque chose te permettant donc bien de deviner que "truc" donnerait un répertoire.
De plus, la simple écriture du chemin "/var/log" implique aussi le fait que "/var" est à la base un répertoire. De fait si on lie "/var/log/truc" à "/var", le nom "truc" pointant sur le même inode que "var/" amène fatalement la conclusion que "truc" est lui aussi un répertoire.

Ainsi si on reprend l'hypothèse de "/var/log/truc" lié à "/var" et qu'on demande une commande récursive sur /var, on peut redérouler la même recherche que dans mon post précédent

• lecture de l'inode 2 (premier inode racine d'un FS). C'est un dossier (type=d) donc lecture des datas au format "dossier" (2 colonnes: nom et inum)
• recherche dans ces datas le nom "var". Il est inum 131075 (véritable numéro de l'inode var/ sur mon OS)
• lecture de l'inode 131075. C'est un dossier (type=d) donc lecture des datas au format "dossier" (2 colonnes: nom et inum)
• traitement de tous les fichiers et dossiers qu'il contient. A un moment donné ce traitement arrive sur le nom "log". Il est inum 674846 (là aussi véritable numéro chez moi)
• lecture de l'inode 674846. C'est un dossier (type=d) donc lecture des datas au format "dossier" (2 colonnes: nom et inum)
• traitement de tous les fichiers et dossiers qu'il contient. A un moment donné ce traitement arrive sur le nom "truc". Il est inum 131075 puisqu'il est relié au même inode que var/
• lecture de l'inode 131075. C'est un dossier (type=d) donc lecture des datas au format "dossier" (2 colonnes: nom et inum)
• traitement de tous les fichiers et dossiers qu'il contient. A un moment donné ce traitement arrive sur le nom "log". Il est inum 674846 (puisqu'on est en train de relire l'inode 131075)
• lecture de l'inode 674846. C'est un dossier (type=d) donc lecture des datas au format "dossier" (2 colonnes: nom et inum)
• traitement de tous les fichiers et dossiers qu'il contient. A un moment donné ce traitement arrive sur le nom "truc". Il est inum 131075 puisqu'il est relié au même inode que var/
• ...

C'est pourquoi le lien physique entre deux dossiers n'est pas possible (y compris pour root où la commande ln -d /var /var/log/truc que je viens de tester m'a été refusée).
La seule solution pour pouvoir offrir ce genre de FS qui accepterait cette possibilité serait qu'à chaque étape il mémorise l'inode traitée et qu'il break s'il retombe sur un numéro déjà enregistré. En n'oubliant pas dans cet algo la possibilité de demander des chemins style /tmp/toto/../toto/../toto/././.. qui, eux, bien que les mêmes inodes traitées sont retraitées plusieurs fois, doivent rester valides (si tu as bien suivi ce plat de nouilles tu vois que c'est équivalent à /tmp). Ce n'est pas impossible mais les performances en souffriraient beaucoup.

[disedorgue]

@sve@r: comment on fait un lien physique sur un répertoire ?

Autant pour moi, dans ton dernier message, tu dis bien que l'on ne peut pas.

D'ailleurs, faut aussi prendre en compte les point de montage qui se font justement sur un répertoire donné. J'imagine mal l'embrouille avec un lien physique sur un répertoire qui est au dessous du répertoire utilisé en point de montage...

[Sve@r]

@sve@r: comment on fait un lien physique sur un répertoire ?

Tape man ln et regarde l'option "-d"

tu dis bien que l'on ne peut pas.

Effectivement le man rajoute en mention "will probably fail due to system restrictions, even for the superuser". Et chez-moi cela a effectivement "failed" (mais si ça avait réussi je me demande ensuite comment aurait réagi mon système sur un ls -R /var )

[disedorgue]

Voici un petit moyen pour "simuler" un hardlink de répertoire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ mkdir foo
$ mkdir bar
$ sudo mount --bind foo bar
$ touch foo/foobar
$ ls bar/
foobar
$ ls -l
total 8
drwxrwxr-x 2 disedorgue disedorgue 4096 févr.  5 13:41 bar
drwxrwxr-x 2 disedorgue disedorgue 4096 févr.  5 13:41 foo
$ ls -il
total 8
9961533 drwxrwxr-x 2 disedorgue disedorgue 4096 févr.  5 13:41 bar
9961533 drwxrwxr-x 2 disedorgue disedorgue 4096 févr.  5 13:41 foo

Techniquement, on peut supprimer foo mais comme un répertoire doit être vide pour être supprimer, bar sera ensuite vide, par contre, je ne sais pas comment ça réagira sur le fs si on crée des fichiers dans le bar et qu'on le demonte ensuite...
Pas osé tester.

[Sve@r]

Voici un petit moyen pour "simuler" un hardlink de répertoire:
...
Pas osé tester.

C'est pour ça qu'il existe la virtualisation.

Bon déjà comme tu l'as dit, ça reste une "simulation", et donc fatalement limitée par les limites de la simulation. Un montage bind étant détectable permettra de protéger l'OS contre une récursivité infinie.

Ce que j'ai fait: /home étant une partition à part, et ayant sur ma machine l'habitude d'avoir root dans /home (homogénéisation des users tous dans home quels qu'ils soient), j'ai créé un dossier /home/root/truc puis monté mount --bind /home /home/root/truc.
De là je peux descendre dans /home, /home/root, /home/root/truc, /home/root/truc/root puis finir dans /home/root/truc/root/truc qui, lui, n'ayant pas hérité du montage de son parent, reste vide.
Donc pas de souci de récursion à l'infini. C'est une jolie simulation mais ça reste limité au niveau de la simulation et de ce qu'elle offre.

[disedorgue]

Oui, pour ça on est d'accord, mais ce que je n'ai pas testé et que je ne testerais pas sur un fs saint, c'est un truc du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$ mkdir foo
$ mkdir bar
$ sudo mount --bind foo bar
$ rm -rf foo
$ touch bar/foobar
$ sudo umount bar

bon là les commandes sont grossières, mais ici, ce que je me demande, c'est comment réagi le fs, après le umount ?
Est-ce qu'il libère l'inode et élimine bien aussi le fichier foobar, puisque l'inode du répertoire foo est libéré au démontage de bar...
Ou on se rertrouve avec un etat fs bancal...

[Sve@r]

mais ce que je n'ai pas testé et que je ne testerais pas sur un fs saint, c'est un truc du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$ mkdir foo
$ mkdir bar
$ sudo mount --bind foo bar
$ rm -rf foo
$ touch bar/foobar
$ sudo umount bar

bon là les commandes sont grossières, mais ici, ce que je me demande, c'est comment réagi le fs, après le umount ?

Testé (sur un fs monté en ram donc tranquille de ce côté).
Le rm -rf foo est refusé "rm: impossible de supprimer 'foo': Périphérique ou ressource occupé".

[disedorgue]

Pas chez moi, le rm est bien passé

Par contre, je n'ai pas essayé de rajouter un fichier dans le montage bar pour ensuite le démonter.

[Sve@r]

Pas chez moi, le rm est bien passé

Zut, je viens de refaire et là aussi. Dans mon test précédent j'avais dû me positionner cd foo comme un gros débile.
Mais avant le rm j'avais créé un fichier "foo/xxx". Il est bien apparu dans "bar". Et à l'effacement de "foo" évidemment il disparait de "bar".
Et maintenant je peux plus rien créer dans "bar" Chaque commande "touch" ou "mkdir" me répond "mkdir(ou touch selon le cas): impossible de créer le répertoire «...»: Aucun fichier ou dossier de ce type"...
Bon je fais ça sur une VM sur un disque immuable donc au pire un reboot et c'est nettoyé