Parce qu'un répertoire, c'est un fichier séquentiel contenant les entrées du répertoire. Comme en général on ne fait pas "rm *", lorqu'on supprime une entrée dans le répertoire, le système indique simplement que cette entrée est vide, et il n'essaye pas de raccourcir le fichier répertoire. (Pour ce faire, il faudrait tasser les entrées, ce qui serait lent, complexe (il faudrait poser utiliser des mutex pour assurer la l'indivisibilité de l'opération de suppression par rapport aux autres opérations sur le répertoire) et potentiellement dangereux, si une coupure de courrant se produisait pendant l'opération.
Il y a déjà des mutex noyau pour l'accès à la structure de répertoire. En cas d'interuption subite, fsck est sensé retrouver les petits.
Dans la plupart des cas, la récupération des espaces disponibles ne s'impose pas. L'agrandissement et le rétrécissement d'un répertoire en temps réél peuvent avoir des répercussions sur les performances du système de fichier (imaginez un spool de mail). Les systèmes de fichiers considèrent en général que si une entrée de fichier a été effacée, une autre prendra sa place tôt ou tard.
Également, ces changement de structure doivent être compatibles avec les programmes en cours qui ont ouvert le répertoire et qui en listent le contenu, l'ordre doit donc être respecté et les curseurs posés doivent pouvoir être conservés, sauf à garder une copie en mémoire de chaque répertoire ouvert.
Pascal Bourguignon <spam@mouse-potato.com> écrit:
Parce qu'un répertoire, c'est un fichier séquentiel contenant les
entrées du répertoire. Comme en général on ne fait pas "rm *",
lorqu'on supprime une entrée dans le répertoire, le système indique
simplement que cette entrée est vide, et il n'essaye pas de raccourcir
le fichier répertoire. (Pour ce faire, il faudrait tasser les entrées,
ce qui serait lent, complexe (il faudrait poser utiliser des mutex
pour assurer la l'indivisibilité de l'opération de suppression par
rapport aux autres opérations sur le répertoire) et potentiellement
dangereux, si une coupure de courrant se produisait pendant
l'opération.
Il y a déjà des mutex noyau pour l'accès à la structure de répertoire.
En cas d'interuption subite, fsck est sensé retrouver les petits.
Dans la plupart des cas, la récupération des espaces disponibles ne
s'impose pas. L'agrandissement et le rétrécissement d'un répertoire en
temps réél peuvent avoir des répercussions sur les performances du
système de fichier (imaginez un spool de mail). Les systèmes de
fichiers considèrent en général que si une entrée de fichier a été
effacée, une autre prendra sa place tôt ou tard.
Également, ces changement de structure doivent être compatibles avec
les programmes en cours qui ont ouvert le répertoire et qui en listent
le contenu, l'ordre doit donc être respecté et les curseurs posés
doivent pouvoir être conservés, sauf à garder une copie en mémoire de
chaque répertoire ouvert.
Parce qu'un répertoire, c'est un fichier séquentiel contenant les entrées du répertoire. Comme en général on ne fait pas "rm *", lorqu'on supprime une entrée dans le répertoire, le système indique simplement que cette entrée est vide, et il n'essaye pas de raccourcir le fichier répertoire. (Pour ce faire, il faudrait tasser les entrées, ce qui serait lent, complexe (il faudrait poser utiliser des mutex pour assurer la l'indivisibilité de l'opération de suppression par rapport aux autres opérations sur le répertoire) et potentiellement dangereux, si une coupure de courrant se produisait pendant l'opération.
Il y a déjà des mutex noyau pour l'accès à la structure de répertoire. En cas d'interuption subite, fsck est sensé retrouver les petits.
Dans la plupart des cas, la récupération des espaces disponibles ne s'impose pas. L'agrandissement et le rétrécissement d'un répertoire en temps réél peuvent avoir des répercussions sur les performances du système de fichier (imaginez un spool de mail). Les systèmes de fichiers considèrent en général que si une entrée de fichier a été effacée, une autre prendra sa place tôt ou tard.
Également, ces changement de structure doivent être compatibles avec les programmes en cours qui ont ouvert le répertoire et qui en listent le contenu, l'ordre doit donc être respecté et les curseurs posés doivent pouvoir être conservés, sauf à garder une copie en mémoire de chaque répertoire ouvert.
Laurent Wacrenier
nicolas écrit:
par hasard j ai teste de remettre un ficher dans ce repertoire vide ... et bien sa taille est redevenu normale ... je ne comprends pas trop la :S
C'est que le système de fichier a un mecanisme qui permet de nettoyer les répertoires. Là, il suffit qu'il pose la fin du fichier à la fin de la dernière entrée.
nicolas <nico@no-spam.fr> écrit:
par hasard j ai teste de remettre un ficher dans ce repertoire vide ...
et bien sa taille est redevenu normale ...
je ne comprends pas trop la :S
C'est que le système de fichier a un mecanisme qui permet de nettoyer
les répertoires. Là, il suffit qu'il pose la fin du fichier à la fin
de la dernière entrée.
par hasard j ai teste de remettre un ficher dans ce repertoire vide ... et bien sa taille est redevenu normale ... je ne comprends pas trop la :S
C'est que le système de fichier a un mecanisme qui permet de nettoyer les répertoires. Là, il suffit qu'il pose la fin du fichier à la fin de la dernière entrée.
nicolas
Laurent Wacrenier wrote:
Pascal Bourguignon écrit:
Parce qu'un répertoire, c'est un fichier séquentiel contenant les entrées du répertoire. Comme en général on ne fait pas "rm *", lorqu'on supprime une entrée dans le répertoire, le système indique simplement que cette entrée est vide, et il n'essaye pas de raccourcir le fichier répertoire. (Pour ce faire, il faudrait tasser les entrées, ce qui serait lent, complexe (il faudrait poser utiliser des mutex pour assurer la l'indivisibilité de l'opération de suppression par rapport aux autres opérations sur le répertoire) et potentiellement dangereux, si une coupure de courrant se produisait pendant l'opération.
Il y a déjà des mutex noyau pour l'accès à la structure de répertoire. En cas d'interuption subite, fsck est sensé retrouver les petits.
Dans la plupart des cas, la récupération des espaces disponibles ne s'impose pas. L'agrandissement et le rétrécissement d'un répertoire en temps réél peuvent avoir des répercussions sur les performances du système de fichier (imaginez un spool de mail). Les systèmes de fichiers considèrent en général que si une entrée de fichier a été effacée, une autre prendra sa place tôt ou tard.
Également, ces changement de structure doivent être compatibles avec les programmes en cours qui ont ouvert le répertoire et qui en listent le contenu, l'ordre doit donc être respecté et les curseurs posés doivent pouvoir être conservés, sauf à garder une copie en mémoire de chaque répertoire ouvert.
merci a tous pour vos reponses ;) c'est deja beaucoup plus clair.
Laurent Wacrenier wrote:
Pascal Bourguignon <spam@mouse-potato.com> écrit:
Parce qu'un répertoire, c'est un fichier séquentiel contenant les
entrées du répertoire. Comme en général on ne fait pas "rm *",
lorqu'on supprime une entrée dans le répertoire, le système indique
simplement que cette entrée est vide, et il n'essaye pas de raccourcir
le fichier répertoire. (Pour ce faire, il faudrait tasser les entrées,
ce qui serait lent, complexe (il faudrait poser utiliser des mutex
pour assurer la l'indivisibilité de l'opération de suppression par
rapport aux autres opérations sur le répertoire) et potentiellement
dangereux, si une coupure de courrant se produisait pendant
l'opération.
Il y a déjà des mutex noyau pour l'accès à la structure de répertoire.
En cas d'interuption subite, fsck est sensé retrouver les petits.
Dans la plupart des cas, la récupération des espaces disponibles ne
s'impose pas. L'agrandissement et le rétrécissement d'un répertoire en
temps réél peuvent avoir des répercussions sur les performances du
système de fichier (imaginez un spool de mail). Les systèmes de
fichiers considèrent en général que si une entrée de fichier a été
effacée, une autre prendra sa place tôt ou tard.
Également, ces changement de structure doivent être compatibles avec
les programmes en cours qui ont ouvert le répertoire et qui en listent
le contenu, l'ordre doit donc être respecté et les curseurs posés
doivent pouvoir être conservés, sauf à garder une copie en mémoire de
chaque répertoire ouvert.
merci a tous pour vos reponses ;)
c'est deja beaucoup plus clair.
Parce qu'un répertoire, c'est un fichier séquentiel contenant les entrées du répertoire. Comme en général on ne fait pas "rm *", lorqu'on supprime une entrée dans le répertoire, le système indique simplement que cette entrée est vide, et il n'essaye pas de raccourcir le fichier répertoire. (Pour ce faire, il faudrait tasser les entrées, ce qui serait lent, complexe (il faudrait poser utiliser des mutex pour assurer la l'indivisibilité de l'opération de suppression par rapport aux autres opérations sur le répertoire) et potentiellement dangereux, si une coupure de courrant se produisait pendant l'opération.
Il y a déjà des mutex noyau pour l'accès à la structure de répertoire. En cas d'interuption subite, fsck est sensé retrouver les petits.
Dans la plupart des cas, la récupération des espaces disponibles ne s'impose pas. L'agrandissement et le rétrécissement d'un répertoire en temps réél peuvent avoir des répercussions sur les performances du système de fichier (imaginez un spool de mail). Les systèmes de fichiers considèrent en général que si une entrée de fichier a été effacée, une autre prendra sa place tôt ou tard.
Également, ces changement de structure doivent être compatibles avec les programmes en cours qui ont ouvert le répertoire et qui en listent le contenu, l'ordre doit donc être respecté et les curseurs posés doivent pouvoir être conservés, sauf à garder une copie en mémoire de chaque répertoire ouvert.
merci a tous pour vos reponses ;) c'est deja beaucoup plus clair.
