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 ?
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 ?
Tu auras quelque chose comme ça :
truc truc2 truc3 | / | / | / v v v +-----------+ | fichier | +-----------+
L'OS garde un compteur de références sur fichier, et désaloue l'espace disque quand tu supprime le dernier lien.
Vu le résultat de ls -l, je penche pour la 2e solution ;
Regardes surtout "ls -i".
-- Matthieu
Matthieu Moy
Nicolas Pontoizeau <pontoize*NOSPAM*@Efrei.fr.invalid> writes:
Bonjour,
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 ?
Non c'est tout a fait normal. A "hard link" is another name for an existing file;
Je concluerais au contraire que c'est pas du tout normal. Deux liens vers le même fichiers ne prennent pas plus de place qu'un seul. (enfin, la place pour stoquer le nom du fichier et une référence sur l'inode, mais en tout cas, pas un Mo).
-- Matthieu
Nicolas Pontoizeau <pontoize*NOSPAM*@Efrei.fr.invalid> writes:
Bonjour,
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 ?
Non c'est tout a fait normal.
A "hard link" is another name for an existing file;
Je concluerais au contraire que c'est pas du tout normal. Deux liens
vers le même fichiers ne prennent pas plus de place qu'un seul.
(enfin, la place pour stoquer le nom du fichier et une référence sur
l'inode, mais en tout cas, pas un Mo).
Nicolas Pontoizeau <pontoize*NOSPAM*@Efrei.fr.invalid> writes:
Bonjour,
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 ?
Non c'est tout a fait normal. A "hard link" is another name for an existing file;
Je concluerais au contraire que c'est pas du tout normal. Deux liens vers le même fichiers ne prennent pas plus de place qu'un seul. (enfin, la place pour stoquer le nom du fichier et une référence sur l'inode, mais en tout cas, pas un Mo).
-- Matthieu
Nicolas Pontoizeau
Bonjour,
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 ?
Non c'est tout a fait normal. 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.
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 ?
cf la definition info extraite de info coreutils ln.
-- http://www.nicolas.pontoizeau.org/ Nicolas Pontoizeau - Promotion EFREI 2005
Bonjour,
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 ?
Non c'est tout a fait normal.
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.
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 ?
cf la definition info extraite de info coreutils ln.
--
http://www.nicolas.pontoizeau.org/
Nicolas Pontoizeau - Promotion EFREI 2005
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 ?
Non c'est tout a fait normal. 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.
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 ?
cf la definition info extraite de info coreutils ln.
-- http://www.nicolas.pontoizeau.org/ Nicolas Pontoizeau - Promotion EFREI 2005
Vincent Ramos
Matthieu Moy a écrit dans :
Regardes surtout "ls -i".
Je le note dans mes tablettes... Merci.
Matthieu Moy a écrit dans <vpqr7h765np.fsf@ecrins.imag.fr> :
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.
Pour l'impossibilité de lier en dur des fichiers à travers plusieurs systèmes de fichiers, je pense que c'est parce que la table des inodes est contenue dans la partition courante. C'est elle qui donne les équivalences entre les noms et les fichiers. Si des liens durs étaient possibles entre deux fs, où serait stockée l'équivalence noms/fichiers ? Il faudrait pour cela une « méta-table » qui englobe les deux fs.
Je raconte peut-être n'importe quoi : c'est ainsi que je comprends l'affaire et je ne doute pas que d'autres plus au fait que moi sauront corriger.
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.
Pour l'impossibilité de lier en dur des fichiers à travers plusieurs
systèmes de fichiers, je pense que c'est parce que la table des
inodes est contenue dans la partition courante. C'est elle qui donne
les équivalences entre les noms et les fichiers. Si des liens durs
étaient possibles entre deux fs, où serait stockée l'équivalence
noms/fichiers ? Il faudrait pour cela une « méta-table » qui englobe
les deux fs.
Je raconte peut-être n'importe quoi : c'est ainsi que je comprends
l'affaire et je ne doute pas que d'autres plus au fait que moi
sauront corriger.
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.
Pour l'impossibilité de lier en dur des fichiers à travers plusieurs systèmes de fichiers, je pense que c'est parce que la table des inodes est contenue dans la partition courante. C'est elle qui donne les équivalences entre les noms et les fichiers. Si des liens durs étaient possibles entre deux fs, où serait stockée l'équivalence noms/fichiers ? Il faudrait pour cela une « méta-table » qui englobe les deux fs.
Je raconte peut-être n'importe quoi : c'est ainsi que je comprends l'affaire et je ne doute pas que d'autres plus au fait que moi sauront corriger.
Non c'est tout a fait normal. A "hard link" is another name for an existing file;
Je concluerais au contraire que c'est pas du tout normal. Deux liens vers le même fichiers ne prennent pas plus de place qu'un seul. (enfin, la place pour stoquer le nom du fichier et une référence sur l'inode, mais en tout cas, pas un Mo).
Là où je pense que ce décrochage entre la taille réelle d'un répertoire et celle affichée par konqueror ou nautilus devient gênant, c'est que l'espace occupé prétendument par le répertoire et l'espace libre sur le disque ne coïncident plus.
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.
Matthieu Moy a écrit dans <vpqmzrv64ie.fsf@ecrins.imag.fr> :
Non c'est tout a fait normal.
A "hard link" is another name for an existing file;
Je concluerais au contraire que c'est pas du tout normal. Deux liens
vers le même fichiers ne prennent pas plus de place qu'un seul.
(enfin, la place pour stoquer le nom du fichier et une référence sur
l'inode, mais en tout cas, pas un Mo).
Là où je pense que ce décrochage entre la taille réelle d'un
répertoire et celle affichée par konqueror ou nautilus devient
gênant, c'est que l'espace occupé prétendument par le répertoire et
l'espace libre sur le disque ne coïncident plus.
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.
Non c'est tout a fait normal. A "hard link" is another name for an existing file;
Je concluerais au contraire que c'est pas du tout normal. Deux liens vers le même fichiers ne prennent pas plus de place qu'un seul. (enfin, la place pour stoquer le nom du fichier et une référence sur l'inode, mais en tout cas, pas un Mo).
Là où je pense que ce décrochage entre la taille réelle d'un répertoire et celle affichée par konqueror ou nautilus devient gênant, c'est que l'espace occupé prétendument par le répertoire et l'espace libre sur le disque ne coïncident plus.
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.
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.
Pour l'impossibilité de lier en dur des fichiers à travers plusieurs systèmes de fichiers, je pense que c'est parce que la table des inodes est contenue dans la partition courante. C'est elle qui donne les équivalences entre les noms et les fichiers. Si des liens durs étaient possibles entre deux fs, où serait stockée l'équivalence noms/fichiers ? Il faudrait pour cela une « méta-table » qui englobe les deux fs.
La table des inodes n'a rien a voir avec les noms de fichiers. Les noms de fichiers n'existent que dans les repertoires qui sont des fichiers speciaux associant un nom au inode. C'est tout.
Je raconte peut-être n'importe quoi : c'est ainsi que je comprends l'affaire et je ne doute pas que d'autres plus au fait que moi sauront corriger.
Pas grave, ca permet d'apprendre. a+
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.
Pour l'impossibilité de lier en dur des fichiers à travers plusieurs
systèmes de fichiers, je pense que c'est parce que la table des
inodes est contenue dans la partition courante. C'est elle qui donne
les équivalences entre les noms et les fichiers. Si des liens durs
étaient possibles entre deux fs, où serait stockée l'équivalence
noms/fichiers ? Il faudrait pour cela une « méta-table » qui englobe
les deux fs.
La table des inodes n'a rien a voir avec les noms de fichiers. Les noms
de fichiers n'existent que dans les repertoires qui sont des fichiers
speciaux associant un nom au inode. C'est tout.
Je raconte peut-être n'importe quoi : c'est ainsi que je comprends
l'affaire et je ne doute pas que d'autres plus au fait que moi
sauront corriger.
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.
Pour l'impossibilité de lier en dur des fichiers à travers plusieurs systèmes de fichiers, je pense que c'est parce que la table des inodes est contenue dans la partition courante. C'est elle qui donne les équivalences entre les noms et les fichiers. Si des liens durs étaient possibles entre deux fs, où serait stockée l'équivalence noms/fichiers ? Il faudrait pour cela une « méta-table » qui englobe les deux fs.
La table des inodes n'a rien a voir avec les noms de fichiers. Les noms de fichiers n'existent que dans les repertoires qui sont des fichiers speciaux associant un nom au inode. C'est tout.
Je raconte peut-être n'importe quoi : c'est ainsi que je comprends l'affaire et je ne doute pas que d'autres plus au fait que moi sauront corriger.
Pas grave, ca permet d'apprendre. a+
news
news wrote:
Vincent Ramos wrote:
Pour l'impossibilité de lier en dur des fichiers à travers plusieurs systèmes de fichiers, je pense que c'est parce que la table des inodes est contenue dans la partition courante. C'est elle qui donne les équivalences entre les noms et les fichiers. Si des liens durs étaient possibles entre deux fs, où serait stockée l'équivalence noms/fichiers ? Il faudrait pour cela une « méta-table » qui englobe les deux fs.
La table des inodes n'a rien a voir avec les noms de fichiers. Les noms de fichiers n'existent que dans les repertoires qui sont des fichiers speciaux associant un nom au inode. C'est tout.
Cela dit, les liens durs entre partitions distinctes sont bien impossibles a cause des tables d'inodes qui sont specifiques a chaque fs.
news wrote:
Vincent Ramos wrote:
Pour l'impossibilité de lier en dur des fichiers à travers
plusieurs
systèmes de fichiers, je pense que c'est parce que la table des
inodes est contenue dans la partition courante. C'est elle qui donne
les équivalences entre les noms et les fichiers. Si des liens durs
étaient possibles entre deux fs, où serait stockée l'équivalence
noms/fichiers ? Il faudrait pour cela une « méta-table » qui englobe
les deux fs.
La table des inodes n'a rien a voir avec les noms de fichiers. Les noms
de fichiers n'existent que dans les repertoires qui sont des fichiers
speciaux associant un nom au inode. C'est tout.
Cela dit, les liens durs entre partitions distinctes sont bien
impossibles a cause des tables d'inodes qui sont specifiques a chaque fs.
Pour l'impossibilité de lier en dur des fichiers à travers plusieurs systèmes de fichiers, je pense que c'est parce que la table des inodes est contenue dans la partition courante. C'est elle qui donne les équivalences entre les noms et les fichiers. Si des liens durs étaient possibles entre deux fs, où serait stockée l'équivalence noms/fichiers ? Il faudrait pour cela une « méta-table » qui englobe les deux fs.
La table des inodes n'a rien a voir avec les noms de fichiers. Les noms de fichiers n'existent que dans les repertoires qui sont des fichiers speciaux associant un nom au inode. C'est tout.
Cela dit, les liens durs entre partitions distinctes sont bien impossibles a cause des tables d'inodes qui sont specifiques a chaque fs.
Khanh-Dang
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. Celà dépend de l'outil utilisé, je présume. Avec un outil bien conçu,
c'est la taille des inodes qui comptent. Voir la page man de du par exemple, où on apprend que l'option -l permet d'avoir un comportement plus atypique, que tu avais décris pour Konqueror et Nautilus.
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 ?
Il faut comprendre que ce qu'on appelle par abus de langage « fichier » est en fait un « nom de fichier ». Le contenu du fichier lui-même est identifié par un inode. Les noms de fichiers ne sont que des pointeurs vers cet inode.
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.
Celà dépend de l'outil utilisé, je présume. Avec un outil bien conçu,
c'est la taille des inodes qui comptent. Voir la page man de du par
exemple, où on apprend que l'option -l permet d'avoir un comportement
plus atypique, que tu avais décris pour Konqueror et Nautilus.
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 ?
Il faut comprendre que ce qu'on appelle par abus de langage « fichier »
est en fait un « nom de fichier ». Le contenu du fichier lui-même est
identifié par un inode. Les noms de fichiers ne sont que des pointeurs
vers cet inode.
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. Celà dépend de l'outil utilisé, je présume. Avec un outil bien conçu,
c'est la taille des inodes qui comptent. Voir la page man de du par exemple, où on apprend que l'option -l permet d'avoir un comportement plus atypique, que tu avais décris pour Konqueror et Nautilus.
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 ?
Il faut comprendre que ce qu'on appelle par abus de langage « fichier » est en fait un « nom de fichier ». Le contenu du fichier lui-même est identifié par un inode. Les noms de fichiers ne sont que des pointeurs vers cet inode.
Vincent Ramos
news a écrit dans <4264a82a$0$10365$ :
Pour l'impossibilité de lier en dur des fichiers à travers plusieurs systèmes de fichiers, je pense que c'est parce que la table des inodes est contenue dans la partition courante. C'est elle qui donne les équivalences entre les noms et les fichiers. Si des liens durs étaient possibles entre deux fs, où serait stockée l'équivalence noms/fichiers ? Il faudrait pour cela une « méta-table » qui englobe les deux fs.
La table des inodes n'a rien a voir avec les noms de fichiers. Les noms de fichiers n'existent que dans les repertoires qui sont des fichiers speciaux associant un nom au inode. C'est tout.
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.
news a écrit dans <4264a82a$0$10365$636a15ce@news.free.fr> :
Pour l'impossibilité de lier en dur des fichiers à travers plusieurs
systèmes de fichiers, je pense que c'est parce que la table des
inodes est contenue dans la partition courante. C'est elle qui
donne les équivalences entre les noms et les fichiers. Si des liens
durs étaient possibles entre deux fs, où serait stockée
l'équivalence noms/fichiers ? Il faudrait pour cela une «
méta-table » qui englobe les deux fs.
La table des inodes n'a rien a voir avec les noms de fichiers. Les
noms de fichiers n'existent que dans les repertoires qui sont des
fichiers speciaux associant un nom au inode. C'est tout.
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.
Pour l'impossibilité de lier en dur des fichiers à travers plusieurs systèmes de fichiers, je pense que c'est parce que la table des inodes est contenue dans la partition courante. C'est elle qui donne les équivalences entre les noms et les fichiers. Si des liens durs étaient possibles entre deux fs, où serait stockée l'équivalence noms/fichiers ? Il faudrait pour cela une « méta-table » qui englobe les deux fs.
La table des inodes n'a rien a voir avec les noms de fichiers. Les noms de fichiers n'existent que dans les repertoires qui sont des fichiers speciaux associant un nom au inode. C'est tout.
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.
