Tout d'abord, voici ce que je crois avoir compris :
* il existe deux types de liens : les liens hard et les liens symboliques
* deux liens hard porteNT sur le même inode et sont donc sur la mà ªme
partition, et paRtagent les caractéristiques du fichier (proprià ©taire,
groupe, droit etc), ce qui affecte l'un affectera l'autre
* un lien symbolique pointe sur un chemin (relatif ou absolu) que le
noyau va suivre pour trouver le fichier original
Mes questions sont alors :
* Quel est lâintérêt des liens hard par rapport aux lie ns symboliques
(juste un gain de temps pour trouver l'inode original ?)
* Pourquoi un lien hard ne peut-il pas pointer un dossier ?
Tout d'abord, voici ce que je crois avoir compris :
* il existe deux types de liens : les liens hard et les liens symboliques
* deux liens hard porteNT sur le même inode et sont donc sur la mà ªme
partition, et paRtagent les caractéristiques du fichier (proprià ©taire,
groupe, droit etc), ce qui affecte l'un affectera l'autre
* un lien symbolique pointe sur un chemin (relatif ou absolu) que le
noyau va suivre pour trouver le fichier original
Mes questions sont alors :
* Quel est lâintérêt des liens hard par rapport aux lie ns symboliques
(juste un gain de temps pour trouver l'inode original ?)
* Pourquoi un lien hard ne peut-il pas pointer un dossier ?
Tout d'abord, voici ce que je crois avoir compris :
* il existe deux types de liens : les liens hard et les liens symboliques
* deux liens hard porteNT sur le même inode et sont donc sur la mà ªme
partition, et paRtagent les caractéristiques du fichier (proprià ©taire,
groupe, droit etc), ce qui affecte l'un affectera l'autre
* un lien symbolique pointe sur un chemin (relatif ou absolu) que le
noyau va suivre pour trouver le fichier original
Mes questions sont alors :
* Quel est lâintérêt des liens hard par rapport aux lie ns symboliques
(juste un gain de temps pour trouver l'inode original ?)
* Pourquoi un lien hard ne peut-il pas pointer un dossier ?
* Pourquoi un lien hard ne peut-il pas pointer un dossier ?
Parce qu'en cas d'effacement du directory d'origine le hard link (et
sa descendance) persisterait, ce qui serait très dangereux question
sécurité; à la différence du symlink qui se voyant privé de sa source
devient inutile à la seconde de la destruction du fichier/directory
* Pourquoi un lien hard ne peut-il pas pointer un dossier ?
Parce qu'en cas d'effacement du directory d'origine le hard link (et
sa descendance) persisterait, ce qui serait très dangereux question
sécurité; à la différence du symlink qui se voyant privé de sa source
devient inutile à la seconde de la destruction du fichier/directory
* Pourquoi un lien hard ne peut-il pas pointer un dossier ?
Parce qu'en cas d'effacement du directory d'origine le hard link (et
sa descendance) persisterait, ce qui serait très dangereux question
sécurité; à la différence du symlink qui se voyant privé de sa source
devient inutile à la seconde de la destruction du fichier/directory
Avec une exception, les références . et .., sont des hard links créés
automatiquement lors de la création d'un répertoire. C'est pour quoi,
le nombre d'inodes dd'un répertoire s'incrémente à mesure que l'on
rajoute des sous répertoires. Information peu importante, mais j'à ©tais
resté sur les fesses quand mon prof de systèmes d'exploitations nous
avait expliqué ça.
Avec une exception, les références . et .., sont des hard links créés
automatiquement lors de la création d'un répertoire. C'est pour quoi,
le nombre d'inodes dd'un répertoire s'incrémente à mesure que l'on
rajoute des sous répertoires. Information peu importante, mais j'à ©tais
resté sur les fesses quand mon prof de systèmes d'exploitations nous
avait expliqué ça.
Avec une exception, les références . et .., sont des hard links créés
automatiquement lors de la création d'un répertoire. C'est pour quoi,
le nombre d'inodes dd'un répertoire s'incrémente à mesure que l'on
rajoute des sous répertoires. Information peu importante, mais j'à ©tais
resté sur les fesses quand mon prof de systèmes d'exploitations nous
avait expliqué ça.
* un lien symbolique pointe sur un chemin (relatif ou absolu) que le
noyau va suivre pour trouver le fichier original
Correct, sauf que ce n'est pas le kernel qui suit quoique ce soit mais le FS.
* Quel est lâintérêt des liens hard par rapport aux li ens symboliques
(juste un gain de temps pour trouver l'inode original ?)
En cas d'effacement du fichier original le hard link (et donc le
contenu original du fichier) persiste tant que tous les hard links n'ont pas
été détruits.
* Pourquoi un lien hard ne peut-il pas pointer un dossier ?
Parce qu'en cas d'effacement du directory d'origine le hard link (et
sa descendance) persisterait, ce qui serait très dangereux question
sécurité; à la différence du symlink qui se voyant pr ivé de sa source
devient inutile à la seconde de la destruction du fichier/directory d'org.
Mais surtout pour une raison simple: le hard link est impossible en
cross-device puisque qu'on peut facilement trouver le même n° d 'inode sur 2
devices différents; donc on ne va pas permettre un demi-travail.
* un lien symbolique pointe sur un chemin (relatif ou absolu) que le
noyau va suivre pour trouver le fichier original
Correct, sauf que ce n'est pas le kernel qui suit quoique ce soit mais le FS.
* Quel est lâintérêt des liens hard par rapport aux li ens symboliques
(juste un gain de temps pour trouver l'inode original ?)
En cas d'effacement du fichier original le hard link (et donc le
contenu original du fichier) persiste tant que tous les hard links n'ont pas
été détruits.
* Pourquoi un lien hard ne peut-il pas pointer un dossier ?
Parce qu'en cas d'effacement du directory d'origine le hard link (et
sa descendance) persisterait, ce qui serait très dangereux question
sécurité; à la différence du symlink qui se voyant pr ivé de sa source
devient inutile à la seconde de la destruction du fichier/directory d'org.
Mais surtout pour une raison simple: le hard link est impossible en
cross-device puisque qu'on peut facilement trouver le même n° d 'inode sur 2
devices différents; donc on ne va pas permettre un demi-travail.
* un lien symbolique pointe sur un chemin (relatif ou absolu) que le
noyau va suivre pour trouver le fichier original
Correct, sauf que ce n'est pas le kernel qui suit quoique ce soit mais le FS.
* Quel est lâintérêt des liens hard par rapport aux li ens symboliques
(juste un gain de temps pour trouver l'inode original ?)
En cas d'effacement du fichier original le hard link (et donc le
contenu original du fichier) persiste tant que tous les hard links n'ont pas
été détruits.
* Pourquoi un lien hard ne peut-il pas pointer un dossier ?
Parce qu'en cas d'effacement du directory d'origine le hard link (et
sa descendance) persisterait, ce qui serait très dangereux question
sécurité; à la différence du symlink qui se voyant pr ivé de sa source
devient inutile à la seconde de la destruction du fichier/directory d'org.
Mais surtout pour une raison simple: le hard link est impossible en
cross-device puisque qu'on peut facilement trouver le même n° d 'inode sur 2
devices différents; donc on ne va pas permettre un demi-travail.
> Correct, sauf que ce n'est pas le kernel qui suit quoique ce soit mais le
> FS.
Même si la cible du lien est sur une autre partition ?
Le FS étant géré par le noyau (si j'ai bien compris) n'est -ce pas la
partie gestion de fichier du noyau qui le gère, donc le noyau ?
> En cas d'effacement du fichier original le hard link (et donc le
> contenu original du fichier) persiste tant que tous les hard links n'ont
> pas été détruits.
Oui effectivement, je ne l'avais pas dit, mais je le savais.
En fait je pensais dans l'optique d'un utilisateur ou administrateur syst ème.
Ou plus simplement, quand privilégiez vous le hard link au symlink ?
> Parce qu'en cas d'effacement du directory d'origine le hard link (et
> sa descendance) persisterait, ce qui serait très dangereux question
> sécurité; à la différence du symlink qui se voyant privé de sa source
> devient inutile à la seconde de la destruction du fichier/director y d'org.
Le même problème n'est-il pas présent dans le cas d'un lie n hard sur
un fichier quoique avec moins de fichier en général
sans compter, qu'il me suffirait de recréer l'arborescence du dossier
que je veux linker et ensuite de faire des liens hard sur tous les
fichiers contenu dans l'arborescence.
> Mais surtout pour une raison simple: le hard link est impossible en
> cross-device puisque qu'on peut facilement trouver le même n° d'inode sur 2
> devices différents; donc on ne va pas permettre un demi-travail.
Si j'ai bien compris, c'est ce que je disais trivialement lorsque
jâécrivais que l'on ne peut pas avoir de hard link sur deux partitions
différentes.
mais le même problèmes se posent alors avec les fichiers.
Je vous priE de m'excuser si je pose trop de question, mais cette
histoire de lien me perturbe.
Est ce que les liens hard ont un réel intérêt ou ont ils j uste une
solution élégante à un problème qui ne se pose plus o u presque pas ?
> Correct, sauf que ce n'est pas le kernel qui suit quoique ce soit mais le
> FS.
Même si la cible du lien est sur une autre partition ?
Le FS étant géré par le noyau (si j'ai bien compris) n'est -ce pas la
partie gestion de fichier du noyau qui le gère, donc le noyau ?
> En cas d'effacement du fichier original le hard link (et donc le
> contenu original du fichier) persiste tant que tous les hard links n'ont
> pas été détruits.
Oui effectivement, je ne l'avais pas dit, mais je le savais.
En fait je pensais dans l'optique d'un utilisateur ou administrateur syst ème.
Ou plus simplement, quand privilégiez vous le hard link au symlink ?
> Parce qu'en cas d'effacement du directory d'origine le hard link (et
> sa descendance) persisterait, ce qui serait très dangereux question
> sécurité; à la différence du symlink qui se voyant privé de sa source
> devient inutile à la seconde de la destruction du fichier/director y d'org.
Le même problème n'est-il pas présent dans le cas d'un lie n hard sur
un fichier quoique avec moins de fichier en général
sans compter, qu'il me suffirait de recréer l'arborescence du dossier
que je veux linker et ensuite de faire des liens hard sur tous les
fichiers contenu dans l'arborescence.
> Mais surtout pour une raison simple: le hard link est impossible en
> cross-device puisque qu'on peut facilement trouver le même n° d'inode sur 2
> devices différents; donc on ne va pas permettre un demi-travail.
Si j'ai bien compris, c'est ce que je disais trivialement lorsque
jâécrivais que l'on ne peut pas avoir de hard link sur deux partitions
différentes.
mais le même problèmes se posent alors avec les fichiers.
Je vous priE de m'excuser si je pose trop de question, mais cette
histoire de lien me perturbe.
Est ce que les liens hard ont un réel intérêt ou ont ils j uste une
solution élégante à un problème qui ne se pose plus o u presque pas ?
> Correct, sauf que ce n'est pas le kernel qui suit quoique ce soit mais le
> FS.
Même si la cible du lien est sur une autre partition ?
Le FS étant géré par le noyau (si j'ai bien compris) n'est -ce pas la
partie gestion de fichier du noyau qui le gère, donc le noyau ?
> En cas d'effacement du fichier original le hard link (et donc le
> contenu original du fichier) persiste tant que tous les hard links n'ont
> pas été détruits.
Oui effectivement, je ne l'avais pas dit, mais je le savais.
En fait je pensais dans l'optique d'un utilisateur ou administrateur syst ème.
Ou plus simplement, quand privilégiez vous le hard link au symlink ?
> Parce qu'en cas d'effacement du directory d'origine le hard link (et
> sa descendance) persisterait, ce qui serait très dangereux question
> sécurité; à la différence du symlink qui se voyant privé de sa source
> devient inutile à la seconde de la destruction du fichier/director y d'org.
Le même problème n'est-il pas présent dans le cas d'un lie n hard sur
un fichier quoique avec moins de fichier en général
sans compter, qu'il me suffirait de recréer l'arborescence du dossier
que je veux linker et ensuite de faire des liens hard sur tous les
fichiers contenu dans l'arborescence.
> Mais surtout pour une raison simple: le hard link est impossible en
> cross-device puisque qu'on peut facilement trouver le même n° d'inode sur 2
> devices différents; donc on ne va pas permettre un demi-travail.
Si j'ai bien compris, c'est ce que je disais trivialement lorsque
jâécrivais que l'on ne peut pas avoir de hard link sur deux partitions
différentes.
mais le même problèmes se posent alors avec les fichiers.
Je vous priE de m'excuser si je pose trop de question, mais cette
histoire de lien me perturbe.
Est ce que les liens hard ont un réel intérêt ou ont ils j uste une
solution élégante à un problème qui ne se pose plus o u presque pas ?
On Tue, 12 Jul 2011 16:36:07 +0100, Etienne CROMBEZ
wrote:
Je remets le post sur la ML.
...Correct, sauf que ce n'est pas le kernel qui suit quoique ce soit mais le
FS.
Même si la cible du lien est sur une autre partition ?
Le FS étant géré par le noyau (si j'ai bien compris) n'est-ce pas la
partie gestion de fichier du noyau qui le gère, donc le noyau ?
Non, ce sont 2 choses différentes; ça n'est pas parce que le kernel a intégré
la gestion de différents *drivers* que ces drivers font partie intégrante du
kernel - ça n'est qu'une facilité.
...En cas d'effacement du fichier original le hard link (et donc le
contenu original du fichier) persiste tant que tous les hard links n'ont
pas été détruits.
Oui effectivement, je ne l'avais pas dit, mais je le savais.
En fait je pensais dans l'optique d'un utilisateur ou administrateur système.
Ou plus simplement, quand privilégiez vous le hard link au symlink ?
Perso je n'utilise jamais de hard link afin d'éviter que des infos sensibles
ne traînent n'importe où.
Certains programmes l'utilisent afin de facilement "déplacer" les fichiers de
conf par exemple de /var/.... vers /etc/.... (eg: hylafax).
On Tue, 12 Jul 2011 16:36:07 +0100, Etienne CROMBEZ
<etienne.crombez@gmail.com> wrote:
Je remets le post sur la ML.
...
Correct, sauf que ce n'est pas le kernel qui suit quoique ce soit mais le
FS.
Même si la cible du lien est sur une autre partition ?
Le FS étant géré par le noyau (si j'ai bien compris) n'est-ce pas la
partie gestion de fichier du noyau qui le gère, donc le noyau ?
Non, ce sont 2 choses différentes; ça n'est pas parce que le kernel a intégré
la gestion de différents *drivers* que ces drivers font partie intégrante du
kernel - ça n'est qu'une facilité.
...
En cas d'effacement du fichier original le hard link (et donc le
contenu original du fichier) persiste tant que tous les hard links n'ont
pas été détruits.
Oui effectivement, je ne l'avais pas dit, mais je le savais.
En fait je pensais dans l'optique d'un utilisateur ou administrateur système.
Ou plus simplement, quand privilégiez vous le hard link au symlink ?
Perso je n'utilise jamais de hard link afin d'éviter que des infos sensibles
ne traînent n'importe où.
Certains programmes l'utilisent afin de facilement "déplacer" les fichiers de
conf par exemple de /var/.... vers /etc/.... (eg: hylafax).
On Tue, 12 Jul 2011 16:36:07 +0100, Etienne CROMBEZ
wrote:
Je remets le post sur la ML.
...Correct, sauf que ce n'est pas le kernel qui suit quoique ce soit mais le
FS.
Même si la cible du lien est sur une autre partition ?
Le FS étant géré par le noyau (si j'ai bien compris) n'est-ce pas la
partie gestion de fichier du noyau qui le gère, donc le noyau ?
Non, ce sont 2 choses différentes; ça n'est pas parce que le kernel a intégré
la gestion de différents *drivers* que ces drivers font partie intégrante du
kernel - ça n'est qu'une facilité.
...En cas d'effacement du fichier original le hard link (et donc le
contenu original du fichier) persiste tant que tous les hard links n'ont
pas été détruits.
Oui effectivement, je ne l'avais pas dit, mais je le savais.
En fait je pensais dans l'optique d'un utilisateur ou administrateur système.
Ou plus simplement, quand privilégiez vous le hard link au symlink ?
Perso je n'utilise jamais de hard link afin d'éviter que des infos sensibles
ne traînent n'importe où.
Certains programmes l'utilisent afin de facilement "déplacer" les fichiers de
conf par exemple de /var/.... vers /etc/.... (eg: hylafax).
Pourquoi?
C'est dans la logique *ix: ne jamais recréer ce qui existe déjà et
réutiliser
au maximum l'existant.
Pourquoi?
C'est dans la logique *ix: ne jamais recréer ce qui existe déjà et
réutiliser
au maximum l'existant.
Pourquoi?
C'est dans la logique *ix: ne jamais recréer ce qui existe déjà et
réutiliser
au maximum l'existant.
>>> En cas d'effacement du fichier original le hard link (et donc le
>>> contenu original du fichier) persiste tant que tous les hard links n'ont
>>> pas été détruits.
>>
>> Oui effectivement, je ne l'avais pas dit, mais je le savais.
>> En fait je pensais dans l'optique d'un utilisateur ou administrateur système.
>> Ou plus simplement, quand privilégiez vous le hard link au symlink ?
>
> Perso je n'utilise jamais de hard link afin d'éviter que des infos sensibles
> ne traînent n'importe où.
> Certains programmes l'utilisent afin de facilement "déplacer" les fichiers de
> conf par exemple de /var/.... vers /etc/.... (eg: hylafax).
C'est aussi le cas dans maildir : le message réçu est écrit dans dir/tmp
puis un lien hard est mis dans dir/new et le lien de dir/tmp est effacé.
Quand le meeeage est lu même manipulation de dir/new vers dir/cur
l'appel système de création du hardlink est en effet atomique. ça permet
de ne pas faire de locks.
>>> En cas d'effacement du fichier original le hard link (et donc le
>>> contenu original du fichier) persiste tant que tous les hard links n'ont
>>> pas été détruits.
>>
>> Oui effectivement, je ne l'avais pas dit, mais je le savais.
>> En fait je pensais dans l'optique d'un utilisateur ou administrateur système.
>> Ou plus simplement, quand privilégiez vous le hard link au symlink ?
>
> Perso je n'utilise jamais de hard link afin d'éviter que des infos sensibles
> ne traînent n'importe où.
> Certains programmes l'utilisent afin de facilement "déplacer" les fichiers de
> conf par exemple de /var/.... vers /etc/.... (eg: hylafax).
C'est aussi le cas dans maildir : le message réçu est écrit dans dir/tmp
puis un lien hard est mis dans dir/new et le lien de dir/tmp est effacé.
Quand le meeeage est lu même manipulation de dir/new vers dir/cur
l'appel système de création du hardlink est en effet atomique. ça permet
de ne pas faire de locks.
>>> En cas d'effacement du fichier original le hard link (et donc le
>>> contenu original du fichier) persiste tant que tous les hard links n'ont
>>> pas été détruits.
>>
>> Oui effectivement, je ne l'avais pas dit, mais je le savais.
>> En fait je pensais dans l'optique d'un utilisateur ou administrateur système.
>> Ou plus simplement, quand privilégiez vous le hard link au symlink ?
>
> Perso je n'utilise jamais de hard link afin d'éviter que des infos sensibles
> ne traînent n'importe où.
> Certains programmes l'utilisent afin de facilement "déplacer" les fichiers de
> conf par exemple de /var/.... vers /etc/.... (eg: hylafax).
C'est aussi le cas dans maildir : le message réçu est écrit dans dir/tmp
puis un lien hard est mis dans dir/new et le lien de dir/tmp est effacé.
Quand le meeeage est lu même manipulation de dir/new vers dir/cur
l'appel système de création du hardlink est en effet atomique. ça permet
de ne pas faire de locks.
Un autre utilité sympathique du hardlink (la seule que j'utilise à
ma connaissance), c'est de permettre de la sauvegarde avec
historique sur un disque sans avoir à dupliquer les fichiers qui
n'ont pas bougé entre deux sauvegardes (dirvish ou tout simplement
rsync sur lequel repose le premier).
Un autre utilité sympathique du hardlink (la seule que j'utilise à
ma connaissance), c'est de permettre de la sauvegarde avec
historique sur un disque sans avoir à dupliquer les fichiers qui
n'ont pas bougé entre deux sauvegardes (dirvish ou tout simplement
rsync sur lequel repose le premier).
Un autre utilité sympathique du hardlink (la seule que j'utilise à
ma connaissance), c'est de permettre de la sauvegarde avec
historique sur un disque sans avoir à dupliquer les fichiers qui
n'ont pas bougé entre deux sauvegardes (dirvish ou tout simplement
rsync sur lequel repose le premier).
Bonjour à tous,
Ma question ne concerne pas directement Debian mais plutôt UNIX, aussi
je m'excuse d'avance pour le hors sujet.
Ma question est sans doute assez trivial, mais je m’intéresse, pour ma
culture personnelle, aux différents type de liens.
Mes questions sont alors :
* Quel est l’intérêt des liens hard par rapport aux liens symboliques
(juste un gain de temps pour trouver l'inode original ?)
* Pourquoi un lien hard ne peut-il pas pointer un dossier ?
Bonjour à tous,
Ma question ne concerne pas directement Debian mais plutôt UNIX, aussi
je m'excuse d'avance pour le hors sujet.
Ma question est sans doute assez trivial, mais je m’intéresse, pour ma
culture personnelle, aux différents type de liens.
Mes questions sont alors :
* Quel est l’intérêt des liens hard par rapport aux liens symboliques
(juste un gain de temps pour trouver l'inode original ?)
* Pourquoi un lien hard ne peut-il pas pointer un dossier ?
Bonjour à tous,
Ma question ne concerne pas directement Debian mais plutôt UNIX, aussi
je m'excuse d'avance pour le hors sujet.
Ma question est sans doute assez trivial, mais je m’intéresse, pour ma
culture personnelle, aux différents type de liens.
Mes questions sont alors :
* Quel est l’intérêt des liens hard par rapport aux liens symboliques
(juste un gain de temps pour trouver l'inode original ?)
* Pourquoi un lien hard ne peut-il pas pointer un dossier ?