Je n'arrive pas à comprendre comment les liens durs sont pris en
compte dans le calcul de l'espace qu'occupent des données sur un
support.
Par exemple : j'ai un fichier de 1 Mo. J'en créé un lien dur. Cela ne
devrait pas diminuer l'espace disque occupé, puisque je ne fais
qu'ajouter une référence vers ce fichier. Si je vérifie avec la
commande du, la taille occupée par le répertoire ne change en effet
pas (toujours 1 Mo).
Or, l'explorateur de fichiers de KDE, konqueror, me dit que le
répertoire contient 2 Mo de données, que ce soit dans l'affichage de
la barre d'état ou en demandant les propriétés du dossier. De même
avec nautilus de Gnome. Peut-on considérer que c'est un bug ?
D'autres part, soient les commandes ln truc truc2 puis ln truc2
truc3. Est-ce que truc3 sera un lien dur du lien dur truc2 ou de
truc ? Vu le résultat de ls -l, je penche pour la 2e solution ; mais
ce que je ne comprends pas, c'est pourquoi : il est donc impossible
de faire un lien dur vers un lien dur ?
Merci pour cette réponse. J'essaie de mieux comprendre : je lis « Chaque système de fichiers tient à jour une table des descripteurs des fichiers qu'utilise le système d'exploitation pour accéder aux fichiers. Cette table se compose pour chaque fichier, d'une entrée appelée inode, repérée par un index appelé le numéro d'inode » <http://www.ac-creteil.fr/reseaux/systemes/linux/systemes-fichiers.html> ou encore <http://vip.cs.utsa.edu/classes/cs3733f2001/notes/FilesOld.html>, section « Inodes ».
Mais quand on en arrive à la section « Links », je suis perdu. Je vais tenter de me creuser un peu plus la cervelle.
En fait, un lien "dur", c'est une entree dans un repertoire associant un nom a un inode. L'inode est unique mais peut se voir associe plusieurs noms de fichiers (ou liens). Un lien symbolique, lui, est un fichier special contenant le chemin vers le fichier qu'il represente. Si on fait ln -s /home/toto/monfichier.txt monlien monlien contiendra "/home/toto/monfichier.txt" Par contre le systeme de fichier le suivra automatiquement par defaut.
Y'avait une commande pour voir l'interieur d'un repertoire, mais je l'ai oubliee. C'est dommage, ca permet de mieux voir.
Vincent Ramos wrote:
Merci pour cette réponse. J'essaie de mieux comprendre : je lis
« Chaque système de fichiers tient à jour une table des descripteurs
des fichiers qu'utilise le système d'exploitation pour accéder aux
fichiers. Cette table se compose pour chaque fichier, d'une entrée
appelée inode, repérée par un index appelé le numéro d'inode »
<http://www.ac-creteil.fr/reseaux/systemes/linux/systemes-fichiers.html>
ou encore
<http://vip.cs.utsa.edu/classes/cs3733f2001/notes/FilesOld.html>,
section « Inodes ».
Mais quand on en arrive à la section « Links », je suis perdu. Je vais
tenter de me creuser un peu plus la cervelle.
En fait, un lien "dur", c'est une entree dans un repertoire associant un
nom a un inode. L'inode est unique mais peut se voir associe plusieurs
noms de fichiers (ou liens).
Un lien symbolique, lui, est un fichier special contenant le chemin vers
le fichier qu'il represente.
Si on fait ln -s /home/toto/monfichier.txt monlien
monlien contiendra "/home/toto/monfichier.txt"
Par contre le systeme de fichier le suivra automatiquement par defaut.
Y'avait une commande pour voir l'interieur d'un repertoire, mais je l'ai
oubliee. C'est dommage, ca permet de mieux voir.
Merci pour cette réponse. J'essaie de mieux comprendre : je lis « Chaque système de fichiers tient à jour une table des descripteurs des fichiers qu'utilise le système d'exploitation pour accéder aux fichiers. Cette table se compose pour chaque fichier, d'une entrée appelée inode, repérée par un index appelé le numéro d'inode » <http://www.ac-creteil.fr/reseaux/systemes/linux/systemes-fichiers.html> ou encore <http://vip.cs.utsa.edu/classes/cs3733f2001/notes/FilesOld.html>, section « Inodes ».
Mais quand on en arrive à la section « Links », je suis perdu. Je vais tenter de me creuser un peu plus la cervelle.
En fait, un lien "dur", c'est une entree dans un repertoire associant un nom a un inode. L'inode est unique mais peut se voir associe plusieurs noms de fichiers (ou liens). Un lien symbolique, lui, est un fichier special contenant le chemin vers le fichier qu'il represente. Si on fait ln -s /home/toto/monfichier.txt monlien monlien contiendra "/home/toto/monfichier.txt" Par contre le systeme de fichier le suivra automatiquement par defaut.
Y'avait une commande pour voir l'interieur d'un repertoire, mais je l'ai oubliee. C'est dommage, ca permet de mieux voir.
Vincent Ramos
news a écrit dans <4264d42a$0$6811$ :
En fait, un lien "dur", c'est une entree dans un repertoire associant un nom a un inode. L'inode est unique mais peut se voir associe plusieurs noms de fichiers (ou liens).
OK.
Y'avait une commande pour voir l'interieur d'un repertoire, mais je l'ai oubliee. C'est dommage, ca permet de mieux voir.
Ce ne serait pas stat ?
news a écrit dans <4264d42a$0$6811$636a15ce@news.free.fr> :
En fait, un lien "dur", c'est une entree dans un repertoire
associant un nom a un inode. L'inode est unique mais peut se voir
associe plusieurs noms de fichiers (ou liens).
OK.
Y'avait une commande pour voir l'interieur d'un repertoire, mais je
l'ai oubliee. C'est dommage, ca permet de mieux voir.
En fait, un lien "dur", c'est une entree dans un repertoire associant un nom a un inode. L'inode est unique mais peut se voir associe plusieurs noms de fichiers (ou liens).
OK.
Y'avait une commande pour voir l'interieur d'un repertoire, mais je l'ai oubliee. C'est dommage, ca permet de mieux voir.
Ce ne serait pas stat ?
news
Vincent Ramos wrote:
news a écrit dans <4264d42a$0$6811$ :
En fait, un lien "dur", c'est une entree dans un repertoire associant un nom a un inode. L'inode est unique mais peut se voir associe plusieurs noms de fichiers (ou liens).
OK.
Y'avait une commande pour voir l'interieur d'un repertoire, mais je l'ai oubliee. C'est dommage, ca permet de mieux voir.
Ce ne serait pas stat ?
non, c'etait un dump. Une autre solution consiste a utiliser debugfs (a manipuler avec beaucoup de precaution). Par defaut (enfin sur ma machine), il ouvre le fs en lecture seule, mais vaut mieux verifier dans la page de man, hein ? :)
On peut ensuite faire un dump d'un repertoire et voir son contenu avec xxd (dans le package vim) dans une autre console. Par contre,rien trouve pour lire l'interieur d'un lien (enfin octet par octet, car debufs permet de faire un stat dessus).
Voir http://www.linux.com/howtos/Ext2fs-Undeletion-Dir-Struct/analyse.shtml (et la page suivante) qui, meme si le but est de recuperer des fichiers effaces est quand meme bien instructif.
Vincent Ramos wrote:
news a écrit dans <4264d42a$0$6811$636a15ce@news.free.fr> :
En fait, un lien "dur", c'est une entree dans un repertoire
associant un nom a un inode. L'inode est unique mais peut se voir
associe plusieurs noms de fichiers (ou liens).
OK.
Y'avait une commande pour voir l'interieur d'un repertoire, mais je
l'ai oubliee. C'est dommage, ca permet de mieux voir.
Ce ne serait pas stat ?
non, c'etait un dump.
Une autre solution consiste a utiliser debugfs (a manipuler avec
beaucoup de precaution). Par defaut (enfin sur ma machine), il ouvre le
fs en lecture seule, mais vaut mieux verifier dans la page de man, hein ? :)
On peut ensuite faire un dump d'un repertoire et voir son contenu avec
xxd (dans le package vim) dans une autre console.
Par contre,rien trouve pour lire l'interieur d'un lien (enfin octet par
octet, car debufs permet de faire un stat dessus).
Voir http://www.linux.com/howtos/Ext2fs-Undeletion-Dir-Struct/analyse.shtml
(et la page suivante) qui, meme si le but est de recuperer des fichiers
effaces est quand meme bien instructif.
En fait, un lien "dur", c'est une entree dans un repertoire associant un nom a un inode. L'inode est unique mais peut se voir associe plusieurs noms de fichiers (ou liens).
OK.
Y'avait une commande pour voir l'interieur d'un repertoire, mais je l'ai oubliee. C'est dommage, ca permet de mieux voir.
Ce ne serait pas stat ?
non, c'etait un dump. Une autre solution consiste a utiliser debugfs (a manipuler avec beaucoup de precaution). Par defaut (enfin sur ma machine), il ouvre le fs en lecture seule, mais vaut mieux verifier dans la page de man, hein ? :)
On peut ensuite faire un dump d'un repertoire et voir son contenu avec xxd (dans le package vim) dans une autre console. Par contre,rien trouve pour lire l'interieur d'un lien (enfin octet par octet, car debufs permet de faire un stat dessus).
Voir http://www.linux.com/howtos/Ext2fs-Undeletion-Dir-Struct/analyse.shtml (et la page suivante) qui, meme si le but est de recuperer des fichiers effaces est quand meme bien instructif.
Vincent Ramos
news a écrit dans <4264db5b$0$3554$ :
Voir http://www.linux.com/howtos/Ext2fs-Undeletion-Dir-Struct/analyse.shtml (et la page suivante) qui, meme si le but est de recuperer des fichiers effaces est quand meme bien instructif.
Merci.
news a écrit dans <4264db5b$0$3554$626a14ce@news.free.fr> :
Voir
http://www.linux.com/howtos/Ext2fs-Undeletion-Dir-Struct/analyse.shtml
(et la page suivante) qui, meme si le but est de recuperer des
fichiers effaces est quand meme bien instructif.
Voir http://www.linux.com/howtos/Ext2fs-Undeletion-Dir-Struct/analyse.shtml (et la page suivante) qui, meme si le but est de recuperer des fichiers effaces est quand meme bien instructif.
Merci.
l'indien
On Tue, 19 Apr 2005 08:41:46 +0200, news wrote:
Vincent Ramos wrote:
Nicolas Pontoizeau a écrit dans <slrnd68fp8.bdv.pontoize*NOSPAM*@choam.unix.efrei.fr> :
A "hard link" is another name for an existing file; the link and the original are indistinguishable. Technically speaking, they share the same inode, and the inode contains all the information about a file--indeed, it is not incorrect to say that the inode _is_ the file. On all existing implementations, you cannot make a hard link to a directory, and hard links cannot cross filesystem boundaries. (These restrictions are not mandated by POSIX, however.)
C'est assez pointu et j'utilise pas trop les hard link donc je suis incapable de te dire pourquoi il en est ainsi.
J'imagine que la restriction concernant les répertoires s'explique si l'on se souvient que toute modification (sauf la suppression tant qu'il reste un lien dur) subie par un des fichiers liés se répercute sur les autres : si fichier1 change de propriétaire ou de contenu, fichier2 aussi. Or, dans le cas des répertoires, ajouter un fichier dans répertoire1 reviendrait à l'ajouter aussi à répertoire2 (si les répertoires sont traités dans les systèmes UNIX comme des fichiers, ce sont des fichiers répertoriant d'autres fichiers, des méta-fichiers, non ?) : dans ce cas, qu'en serait-il ? Est-ce que les fichiers seraient ajoutées réellement ou sous forme de liens ? Pire, comment la suppression de fichiers contenus sous le répertoire serait-elle répercutée ? Si les fichiers effacés sont effacés des deux répertoires liés, c'est dangereux. Si l'effacement n'a pas de répercussion, les deux répertoires ne sont plus identiques.
Non, c'est juste pour eviter de faire des boucles quand on parcourt le systeme de fichier. Eviter quelque chose du genre ln .. toto C'est possible avec les liens symboliques, mais ils permettent de differencier facilement le vrai repertoire du lien, donc, les utilitaire de type find, y font attention.
Ceci n'est pas un vrai problème. Les vrais problèmes sont: - si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais "cd .." ? - les liens sur les répertoires permettraient de s'échapper facilement d'un chroot. C'est un trou de sécurité tellement énorme que ça justifie, en soi, l'interdiction de ces liens.
On Tue, 19 Apr 2005 08:41:46 +0200, news wrote:
Vincent Ramos wrote:
Nicolas Pontoizeau a écrit dans
<slrnd68fp8.bdv.pontoize*NOSPAM*@choam.unix.efrei.fr> :
A "hard link" is another name for an existing file; the link and the
original are indistinguishable. Technically speaking, they share
the same inode, and the inode contains all the information about a
file--indeed, it is not incorrect to say that the inode _is_ the
file. On all existing implementations, you cannot make a hard link
to a
directory, and hard links cannot cross filesystem boundaries.
(These restrictions are not mandated by POSIX, however.)
C'est assez pointu et j'utilise pas trop les hard link donc je suis
incapable de te dire pourquoi il en est ainsi.
J'imagine que la restriction concernant les répertoires s'explique si
l'on se souvient que toute modification (sauf la suppression tant
qu'il reste un lien dur) subie par un des fichiers liés se répercute
sur les autres : si fichier1 change de propriétaire ou de contenu,
fichier2 aussi. Or, dans le cas des répertoires, ajouter un fichier
dans répertoire1 reviendrait à l'ajouter aussi à répertoire2 (si les
répertoires sont traités dans les systèmes UNIX comme des fichiers,
ce sont des fichiers répertoriant d'autres fichiers, des
méta-fichiers, non ?) : dans ce cas, qu'en serait-il ? Est-ce que les
fichiers seraient ajoutées réellement ou sous forme de liens ? Pire,
comment la suppression de fichiers contenus sous le répertoire
serait-elle répercutée ? Si les fichiers effacés sont effacés des
deux répertoires liés, c'est dangereux. Si l'effacement n'a pas de
répercussion, les deux répertoires ne sont plus identiques.
Non, c'est juste pour eviter de faire des boucles quand on parcourt le
systeme de fichier. Eviter quelque chose du genre ln .. toto
C'est possible avec les liens symboliques, mais ils permettent de
differencier facilement le vrai repertoire du lien, donc, les utilitaire
de type find, y font attention.
Ceci n'est pas un vrai problème.
Les vrais problèmes sont:
- si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais
"cd .." ?
- les liens sur les répertoires permettraient de s'échapper facilement
d'un chroot. C'est un trou de sécurité tellement énorme que ça
justifie, en soi, l'interdiction de ces liens.
Nicolas Pontoizeau a écrit dans <slrnd68fp8.bdv.pontoize*NOSPAM*@choam.unix.efrei.fr> :
A "hard link" is another name for an existing file; the link and the original are indistinguishable. Technically speaking, they share the same inode, and the inode contains all the information about a file--indeed, it is not incorrect to say that the inode _is_ the file. On all existing implementations, you cannot make a hard link to a directory, and hard links cannot cross filesystem boundaries. (These restrictions are not mandated by POSIX, however.)
C'est assez pointu et j'utilise pas trop les hard link donc je suis incapable de te dire pourquoi il en est ainsi.
J'imagine que la restriction concernant les répertoires s'explique si l'on se souvient que toute modification (sauf la suppression tant qu'il reste un lien dur) subie par un des fichiers liés se répercute sur les autres : si fichier1 change de propriétaire ou de contenu, fichier2 aussi. Or, dans le cas des répertoires, ajouter un fichier dans répertoire1 reviendrait à l'ajouter aussi à répertoire2 (si les répertoires sont traités dans les systèmes UNIX comme des fichiers, ce sont des fichiers répertoriant d'autres fichiers, des méta-fichiers, non ?) : dans ce cas, qu'en serait-il ? Est-ce que les fichiers seraient ajoutées réellement ou sous forme de liens ? Pire, comment la suppression de fichiers contenus sous le répertoire serait-elle répercutée ? Si les fichiers effacés sont effacés des deux répertoires liés, c'est dangereux. Si l'effacement n'a pas de répercussion, les deux répertoires ne sont plus identiques.
Non, c'est juste pour eviter de faire des boucles quand on parcourt le systeme de fichier. Eviter quelque chose du genre ln .. toto C'est possible avec les liens symboliques, mais ils permettent de differencier facilement le vrai repertoire du lien, donc, les utilitaire de type find, y font attention.
Ceci n'est pas un vrai problème. Les vrais problèmes sont: - si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais "cd .." ? - les liens sur les répertoires permettraient de s'échapper facilement d'un chroot. C'est un trou de sécurité tellement énorme que ça justifie, en soi, l'interdiction de ces liens.
news
l'indien wrote:
On Tue, 19 Apr 2005 08:41:46 +0200, news wrote:
Non, c'est juste pour eviter de faire des boucles quand on parcourt le systeme de fichier. Eviter quelque chose du genre ln .. toto C'est possible avec les liens symboliques, mais ils permettent de differencier facilement le vrai repertoire du lien, donc, les utilitaire de type find, y font attention.
Ceci n'est pas un vrai problème. Les vrais problèmes sont: - si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais "cd .." ? - les liens sur les répertoires permettraient de s'échapper facilement d'un chroot. C'est un trou de sécurité tellement énorme que ça justifie, en soi, l'interdiction de ces liens.
Issu de "Programmation linux 2.0", par Rémy Card, Eric Dumas et Franck Mevel. p123-124 : "il est impossible de creer des liens sur les repertoires. En effet, l'existence de liens entre repertoires aurait pour effet de transformer l'arborescence des fichiers en graphe pouvant contenir des cycles, et le noyau pourrait boucler sans fin lors de la résolution de noms de fichiers".
l'indien wrote:
On Tue, 19 Apr 2005 08:41:46 +0200, news wrote:
Non, c'est juste pour eviter de faire des boucles quand on parcourt le
systeme de fichier. Eviter quelque chose du genre ln .. toto
C'est possible avec les liens symboliques, mais ils permettent de
differencier facilement le vrai repertoire du lien, donc, les utilitaire
de type find, y font attention.
Ceci n'est pas un vrai problème.
Les vrais problèmes sont:
- si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais
"cd .." ?
- les liens sur les répertoires permettraient de s'échapper facilement
d'un chroot. C'est un trou de sécurité tellement énorme que ça
justifie, en soi, l'interdiction de ces liens.
Issu de "Programmation linux 2.0", par Rémy Card, Eric Dumas et Franck
Mevel.
p123-124 :
"il est impossible de creer des liens sur les repertoires. En effet,
l'existence de liens entre repertoires aurait pour effet de transformer
l'arborescence des fichiers en graphe pouvant contenir des cycles, et le
noyau pourrait boucler sans fin lors de la résolution de noms de fichiers".
Non, c'est juste pour eviter de faire des boucles quand on parcourt le systeme de fichier. Eviter quelque chose du genre ln .. toto C'est possible avec les liens symboliques, mais ils permettent de differencier facilement le vrai repertoire du lien, donc, les utilitaire de type find, y font attention.
Ceci n'est pas un vrai problème. Les vrais problèmes sont: - si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais "cd .." ? - les liens sur les répertoires permettraient de s'échapper facilement d'un chroot. C'est un trou de sécurité tellement énorme que ça justifie, en soi, l'interdiction de ces liens.
Issu de "Programmation linux 2.0", par Rémy Card, Eric Dumas et Franck Mevel. p123-124 : "il est impossible de creer des liens sur les repertoires. En effet, l'existence de liens entre repertoires aurait pour effet de transformer l'arborescence des fichiers en graphe pouvant contenir des cycles, et le noyau pourrait boucler sans fin lors de la résolution de noms de fichiers".
Nicolas George
l'indien wrote in message :
Les vrais problèmes sont: - si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais "cd .." ?
Euh, bof, quand même, ça reste quelque chose d'assez anecdotique.
- les liens sur les répertoires permettraient de s'échapper facilement d'un chroot. C'est un trou de sécurité tellement énorme que ça justifie, en soi, l'interdiction de ces liens.
Euh, ça ne le permet que s'il existe déjà un lien dans la prison chroot, ce qui n'est pas complètement évident.
Le vrai problème, ce sont les boucles, mais pour une raison qui n'a pas été évoquée : il faudrait un GC.
l'indien wrote in message <pan.2005.04.19.12.41.23.986567@magic.fr>:
Les vrais problèmes sont:
- si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais
"cd .." ?
Euh, bof, quand même, ça reste quelque chose d'assez anecdotique.
- les liens sur les répertoires permettraient de s'échapper facilement
d'un chroot. C'est un trou de sécurité tellement énorme que ça
justifie, en soi, l'interdiction de ces liens.
Euh, ça ne le permet que s'il existe déjà un lien dans la prison chroot, ce
qui n'est pas complètement évident.
Le vrai problème, ce sont les boucles, mais pour une raison qui n'a pas été
évoquée : il faudrait un GC.
Les vrais problèmes sont: - si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais "cd .." ?
Euh, bof, quand même, ça reste quelque chose d'assez anecdotique.
- les liens sur les répertoires permettraient de s'échapper facilement d'un chroot. C'est un trou de sécurité tellement énorme que ça justifie, en soi, l'interdiction de ces liens.
Euh, ça ne le permet que s'il existe déjà un lien dans la prison chroot, ce qui n'est pas complètement évident.
Le vrai problème, ce sont les boucles, mais pour une raison qui n'a pas été évoquée : il faudrait un GC.
Matthieu Moy
Vincent Ramos writes:
C'est assez absurde et, surtout, déroutant ; l'impression d'écran <http://sivanataraja.free.fr/temp/kde_absurde.png> le montre bien... C'est pour moi un bug gênant : je ne peux connaître l'espace occupé réellement qu'indirectement.
Tu as fait un rapport de bug ?
-- Matthieu
Vincent Ramos <sivanataraja.a_retirer@free.invalid.fr> writes:
C'est assez absurde et, surtout, déroutant ; l'impression d'écran
<http://sivanataraja.free.fr/temp/kde_absurde.png> le montre bien...
C'est pour moi un bug gênant : je ne peux connaître l'espace occupé
réellement qu'indirectement.
C'est assez absurde et, surtout, déroutant ; l'impression d'écran <http://sivanataraja.free.fr/temp/kde_absurde.png> le montre bien... C'est pour moi un bug gênant : je ne peux connaître l'espace occupé réellement qu'indirectement.
Tu as fait un rapport de bug ?
-- Matthieu
Doug713705
Le Mardi 19 Avril 2005 03:54, Vincent Ramos s'est exprimé de la sorte sur fr.comp.os.linux.configuration :
Par exemple, la partition où je stocke mes sauvegardes contient de nombreux liens durs pour les fichiers qui n'ont pas été modifiés d'une sauvegarde à l'autre. Gain de place notable. Or, konqueror me dit que mes répertoires et fichiers de sauvegarde occupent actuellement 78,6 Go mais que l'espace libre sur le disque est de 30,6 Go sur... 44,6 !
C'est assez absurde et, surtout, déroutant ; l'impression d'écran <http://sivanataraja.free.fr/temp/kde_absurde.png> le montre bien... C'est pour moi un bug gênant : je ne peux connaître l'espace occupé réellement qu'indirectement.
Il n'y a, pour moi, rien d'absurde dans ce comportement. Le répertoire /save contient bien 78.6 Go (en tout cas s'il fallait en sauvegarder son contenu exact, c'est la quantité de données qu'il faudrait s'attendre à avoir à stocker). Par contre le point de montage /save ne contient que 30.6 Go sur 44.6. On parle ici d'espace disque et non de quantité de données.
Il me semble que tu confonds répertoire /save et point de montage /save.
Ce n'est que mon avis, il n'y a pas d'offense et j'ai peut être mal compris.
-- @+ Doug [Linux user #307925] - Slackware RuleZ ;-) [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
Le Mardi 19 Avril 2005 03:54, Vincent Ramos s'est exprimé de la sorte sur
fr.comp.os.linux.configuration :
Par exemple, la partition où je stocke mes sauvegardes contient de
nombreux liens durs pour les fichiers qui n'ont pas été modifiés
d'une sauvegarde à l'autre. Gain de place notable. Or, konqueror me
dit que mes répertoires et fichiers de sauvegarde occupent
actuellement 78,6 Go mais que l'espace libre sur le disque est de
30,6 Go sur... 44,6 !
C'est assez absurde et, surtout, déroutant ; l'impression d'écran
<http://sivanataraja.free.fr/temp/kde_absurde.png> le montre bien...
C'est pour moi un bug gênant : je ne peux connaître l'espace occupé
réellement qu'indirectement.
Il n'y a, pour moi, rien d'absurde dans ce comportement. Le répertoire /save
contient bien 78.6 Go (en tout cas s'il fallait en sauvegarder son contenu
exact, c'est la quantité de données qu'il faudrait s'attendre à avoir à
stocker). Par contre le point de montage /save ne contient que 30.6 Go sur
44.6. On parle ici d'espace disque et non de quantité de données.
Il me semble que tu confonds répertoire /save et point de montage /save.
Ce n'est que mon avis, il n'y a pas d'offense et j'ai peut être mal compris.
--
@+
Doug [Linux user #307925] - Slackware RuleZ ;-)
[Pourquoi t'es qui, qu'est ce que tu fais par où ?]
-- Pour me contacter enlever no-spam (2X) --
Le Mardi 19 Avril 2005 03:54, Vincent Ramos s'est exprimé de la sorte sur fr.comp.os.linux.configuration :
Par exemple, la partition où je stocke mes sauvegardes contient de nombreux liens durs pour les fichiers qui n'ont pas été modifiés d'une sauvegarde à l'autre. Gain de place notable. Or, konqueror me dit que mes répertoires et fichiers de sauvegarde occupent actuellement 78,6 Go mais que l'espace libre sur le disque est de 30,6 Go sur... 44,6 !
C'est assez absurde et, surtout, déroutant ; l'impression d'écran <http://sivanataraja.free.fr/temp/kde_absurde.png> le montre bien... C'est pour moi un bug gênant : je ne peux connaître l'espace occupé réellement qu'indirectement.
Il n'y a, pour moi, rien d'absurde dans ce comportement. Le répertoire /save contient bien 78.6 Go (en tout cas s'il fallait en sauvegarder son contenu exact, c'est la quantité de données qu'il faudrait s'attendre à avoir à stocker). Par contre le point de montage /save ne contient que 30.6 Go sur 44.6. On parle ici d'espace disque et non de quantité de données.
Il me semble que tu confonds répertoire /save et point de montage /save.
Ce n'est que mon avis, il n'y a pas d'offense et j'ai peut être mal compris.
-- @+ Doug [Linux user #307925] - Slackware RuleZ ;-) [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
l'indien
On Tue, 19 Apr 2005 13:53:11 +0000, Nicolas George wrote:
l'indien wrote in message :
Les vrais problèmes sont: - si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais "cd .." ?
Euh, bof, quand même, ça reste quelque chose d'assez anecdotique.
Absolument pas. Il y a plein de process qui ont besoin de redescendre. C'est loin d'être trivial.
- les liens sur les répertoires permettraient de s'échapper facilement d'un chroot. C'est un trou de sécurité tellement énorme que ça justifie, en soi, l'interdiction de ces liens.
Euh, ça ne le permet que s'il existe déjà un lien dans la prison chroot, ce qui n'est pas complètement évident.
Non. Il suffit de connaitre le numéro d'inode du répertoire sur lequel on veut créer le lien et c'est gagné. Et justement, on connait toujours le numéro d'inode du répertoire racine de la partition, donc il est trivial de remonter à celle-ci.
Le vrai problème, ce sont les boucles, mais pour une raison qui n'a pas été évoquée : il faudrait un GC.
Les boucles posent un problème à Linux et à la plupart des Unix, en effet, puisqu'ils considèrent que le filesystem est un arbre. Certains OS n'ont aucun problème avec les boucles, ce qui prouve que c'est un problème qui peut être résolu. Néanmoins, résoudre ce problème ne résoudrait pas le trou de sécurité lié aux liens sur les répertoires. Donc, ce n'est pas le point bloquant ici: s'il n'y avait que ce point à résoudre, les patches nécessaires auraient été fait, ce n'est pas si compliqué (le plus gros des patches est à faire dans fsck, en fait...).
On Tue, 19 Apr 2005 13:53:11 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2005.04.19.12.41.23.986567@magic.fr>:
Les vrais problèmes sont:
- si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais
"cd .." ?
Euh, bof, quand même, ça reste quelque chose d'assez anecdotique.
Absolument pas. Il y a plein de process qui ont besoin de redescendre.
C'est loin d'être trivial.
- les liens sur les répertoires permettraient de s'échapper facilement
d'un chroot. C'est un trou de sécurité tellement énorme que ça
justifie, en soi, l'interdiction de ces liens.
Euh, ça ne le permet que s'il existe déjà un lien dans la prison chroot, ce
qui n'est pas complètement évident.
Non. Il suffit de connaitre le numéro d'inode du répertoire sur lequel
on veut créer le lien et c'est gagné. Et justement, on connait toujours
le numéro d'inode du répertoire racine de la partition, donc il est
trivial de remonter à celle-ci.
Le vrai problème, ce sont les boucles, mais pour une raison qui n'a pas été
évoquée : il faudrait un GC.
Les boucles posent un problème à Linux et à la plupart des Unix, en
effet, puisqu'ils considèrent que le filesystem est un arbre. Certains OS
n'ont aucun problème avec les boucles, ce qui prouve que c'est un
problème qui peut être résolu. Néanmoins, résoudre ce problème ne
résoudrait pas le trou de sécurité lié aux liens sur les répertoires.
Donc, ce n'est pas le point bloquant ici: s'il n'y avait que ce point à
résoudre, les patches nécessaires auraient été fait, ce n'est pas si
compliqué (le plus gros des patches est à faire dans fsck, en fait...).
On Tue, 19 Apr 2005 13:53:11 +0000, Nicolas George wrote:
l'indien wrote in message :
Les vrais problèmes sont: - si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais "cd .." ?
Euh, bof, quand même, ça reste quelque chose d'assez anecdotique.
Absolument pas. Il y a plein de process qui ont besoin de redescendre. C'est loin d'être trivial.
- les liens sur les répertoires permettraient de s'échapper facilement d'un chroot. C'est un trou de sécurité tellement énorme que ça justifie, en soi, l'interdiction de ces liens.
Euh, ça ne le permet que s'il existe déjà un lien dans la prison chroot, ce qui n'est pas complètement évident.
Non. Il suffit de connaitre le numéro d'inode du répertoire sur lequel on veut créer le lien et c'est gagné. Et justement, on connait toujours le numéro d'inode du répertoire racine de la partition, donc il est trivial de remonter à celle-ci.
Le vrai problème, ce sont les boucles, mais pour une raison qui n'a pas été évoquée : il faudrait un GC.
Les boucles posent un problème à Linux et à la plupart des Unix, en effet, puisqu'ils considèrent que le filesystem est un arbre. Certains OS n'ont aucun problème avec les boucles, ce qui prouve que c'est un problème qui peut être résolu. Néanmoins, résoudre ce problème ne résoudrait pas le trou de sécurité lié aux liens sur les répertoires. Donc, ce n'est pas le point bloquant ici: s'il n'y avait que ce point à résoudre, les patches nécessaires auraient été fait, ce n'est pas si compliqué (le plus gros des patches est à faire dans fsck, en fait...).
