ln -s confusion des sens

Version imprimable

25/07/2013, 16h36
xavierdestev

ln -s confusion des sens
Bonjour,

Je ne comprends pas la pharase :

Citation:

Il faut créer un lien symbolique de busybox vers /init.

busybox est situé dans /bin et init à la racine /
Code:

1 2 ln -s sbin/busybox init
ou

Code:

ln -s init sbin/busybox

ou autre chose encore?
25/07/2013, 16h46
Invité
Bonjour,
Code:

1 2 3 ln --help Utilisation*: ln [OPTION]... [-T] TARGET LINK_NAME (1er format) [...]
:D

un peu de contexte, pour comprendre la directive
...
?
25/07/2013, 17h02
xavierdestev

Autrement dit, comment la machine comprend les liens symboliques?
Si j'exécutes init et je veux que busybox soit repéré, que dois-je faire?
25/07/2013, 18h26
jack-ft

Citation:

Envoyé par xavierdestev

Bonjour,

Je ne comprends pas la pharase :

busybox est situé dans /bin et init à la racine /

Code:

ln -s sbin/busybox init

ou

Code:

ln -s init sbin/busybox

ou autre chose encore?

Bonjour,
j'utilise comme moyen mnémotechnique que les arguments de 'ln' sont dans le même sens que ceux de 'cp'.
Donc:

Code:

cp truc_qui_existe vers_cible_qui_n_existe_pas_encore

et, de même:

Code:

ln -s truc_qui_existe vers_cible_qui_n_existe_pas_encore

Dans ton cas, à un moment, tu parles de /bin et, à un autre, de sbin. Pourrais-tu choisir?

Si /sbin/busybox existe déjà, mais pas encore /init alors c'est:

Code:

ln -s /sbin/busybox /init

Si /init existe déjà, mais pas encore /sbin/busybox alors c'est:

Code:

ln -s /init /sbin/busybox
25/07/2013, 20h35
Invité

Pas mal ton moyen mnémotechnique. Je me trompe une fois sur deux avec cette commande (car je l'utilise rarement)
26/07/2013, 09h22
xavierdestev

Merci pour la réponse détaillée. C'est vrai que ce moyen mémo-technique est efficace.
26/07/2013, 21h09
ram-0000

Citation:

Envoyé par ecatomb

Pas mal ton moyen mnémotechnique. Je me trompe une fois sur deux avec cette commande (car je l'utilise rarement)

J'achète aussi le moyen mnémotechnique ...
30/07/2013, 22h26
Sve@r

Bonjour
A noter (histoire que la confusion soit encore plus totale), que si on travaille en noms relatifs, alors le nom du fichier cible doit être vu depuis l'endroit où se trouve le lien et non depuis l'endroit où on se trouve lors de la création du lien. Généralement les deux endroits se confondent (on crée le lien là où on se trouve), mais ce n'est pas obligé.

Exemple: je me trouve dans /tmp et je veux créer un lien en relatif de /home/moi/passwd vers /etc/passwd.
Depuis /tmp, le fichier /etc/passwd se nomme (en relatif) "../etc/passwd"
Depuis /home/moi, le fichier /etc/passwd se nomme (en relatif) "../../etc/passwd"
La commande sera alors ln -s ../../etc/passwd ../home/moi/passwd.
Le premier nom "../../etc/passwd" étant le chemin du fichier vu depuis l'endroit où se trouve le lien, à savoir /home/moi
Le second nom "../home/moi/passwd" étant l'endroit où je crée le lien vu depuis ma position "/tmp"
C'est d'ailleurs logique. Lorsque on demande à ouvrir le fichier "/home/moi/passwd", le système va dans "/home/moi" pour ouvrir "passwd". Voyant qu'il s'agit d'un lien, il prend son contenu "../../etc/passwd" comme nouveau fichier à ouvrir ; mais ce nouveau fichier est alors ouvert depuis la position courante "/home/moi".
PS: Et le nom "../etc/passwd" qui est la cible du lien depuis la position /tmp ne sert absolument à rien.
30/07/2013, 23h33
Flodelarab
Bonjour

C'est uniquement parce que tu lui as demandé!
Tu demandes un lien symbolique ( ln -s ) alors il fait un lien qui sera inerprété au dernier moment.
Si tu fais un lien dur ( ln ), je ne crois pas que tu aies besoin de te casser la tête avec la subjectivité.

Attention:
- Les liens en dur doivent être sur la même partition que leur cible
- Pas de liens en dur vers des dossiers
- Les fichiers pointés ne sont effacés que quand tous les liens en dur sont effacés
31/07/2013, 18h48
Sve@r

Citation:

Envoyé par Flodelarab

Bonjour

C'est uniquement parce que tu lui as demandé!

Je pige pas trop cette phrase. Le système n'obéit qu'aux ordres que je lui demande...

Citation:

Envoyé par Flodelarab

Tu demandes un lien symbolique ( ln -s ) alors il fait un lien qui sera interprété au dernier moment.

"Dernier moment" c'est un terme maladroit. Le système de recherche dans un fs est assez basique
1) pour chaque dossier du chemin, le système se place dans le dossier et cherche le nom suivant dans le dossier en question
2) lorsqu'il arrive sur un fichier, le système ouvre alors le fichier et le transmet à la commande.
Toutefois, s'il s'agit d'un lien, alors il ne le transmet pas à la commande mais prend son contenu comme nouveau nom à chercher et retour en 1
Il n'est pas trop question de "dernier moment" ici. Simplement il prend chaque élément et le traite séquentiellement...

Citation:

Envoyé par Flodelarab

Si tu fais un lien dur ( ln ), je ne crois pas que tu aies besoin de te casser la tête avec la subjectivité.

Là non puisque un lien réel n'est qu'un nom relié à un inode déjà existant. Mais là on parle de liens symboliques dont le mécanisme n'est pas du tout le même. Malgré la similitude de la syntaxe, un lien réel crée une liaison entre "nom" et "inode" alors qu'un lien symbolique crée une liaison entre "nom" et "nom".
Dans le premier cas, même en relatif, on gèrera le nom source et le nom cible depuis notre position ce qui est assez facile. Alors que dans le second cas, on gèrera le nom cible depuis la position du nom source ce qui est un poil plus ardu...

Citation:

Envoyé par Flodelarab

Les liens en dur doivent être sur la même partition que leur cible

Fatalement de par leurs natures de liaison supplémentaire vers un inode déjà existant. L'inode est donc obligatoirement sur la même partition que le nom associé

Citation:

Envoyé par Flodelarab

Pas de liens en dur vers des dossiers

Non pas pour un problème technique (un dossier n'est lui-aussi qu'un inode) mais simplement parce qu'ensuite, il serait impossible de distinguer l'un de l'autre et donc toute commande récursive partirait alors en torche infinie...
Accessoirement root a quand-même le droit de créer des liens réels sur des dossiers.

Citation:

Envoyé par Flodelarab

Les fichiers pointés ne sont effacés que quand tous les liens en dur sont effacés

Plus exactement quand le compteur de liens (situé dans l'inode) tombe à 0.
01/08/2013, 21h07
Flodelarab

Citation:

Envoyé par Sve@r

Il n'est pas trop question de "dernier moment" ici. Simplement il prend chaque élément et le traite séquentiellement...

Séquence => temps => dernier moment...

Je maintiens ce que je dis: Si tu fais un lien vers .. et que tu le déplaces, il
aura la valeur relative de l'endroit où il est. Si tu fais un lien dur, l'inode
est fixée une fois pour toute. Et déplacer ne change pas le pointage. D'où l'interprétation au dernier moment des liens symboliques.
01/08/2013, 22h03
Sve@r

Citation:

Envoyé par Flodelarab

Séquence => temps => dernier moment...

Séquence (nf): suite ordonnée. Il n'est nullement question de temps dans cette définition (ni dans aucune autre de ses synonymes).

Citation:

Envoyé par Flodelarab

Je maintiens ce que je dis: Si tu fais un lien vers .. et que tu le déplaces, il aura la valeur relative de l'endroit où il est.

Moui, comme tout nom relatif...

Citation:

Envoyé par Flodelarab

D'où l'interprétation au dernier moment des liens symboliques.

Dernier moment (adv): à l'ultime instant, à la dernière heure, à la dernière minute. Je ne vois pas trop ce que ça vient faire dans une arborescence. Au dernier moment de quoi ? De ta commande ? Et donc quand il n'y a pas de commande tu ne peux pas dire vers où il pointe ? Tu veux vraiment nous faire croire qu'un lien symbolique est un truc "magique" qui s'active et se désactive en temps réel ???

Code:

1
2
3
4
5
6
7
8
9
10
11
$ cd /home
$ ln -s .. parent
$ ls parent
bin  boot  dev  etc  home  initrd.img  lib  lost+found  media  mnt  opt  proc  root  sbin  selinux  srv  sys  tmp  usr  var  vmlinuz
$ cd moi
$ mv ../parent .
$ ls parent
moi
$ rm parent
rm*: supprimer lien symbolique «*parent*»*? o
$

Citation:
Envoyé par Flodelarab
Code:

1 2 3 4 5 6 7 8 9 10 11 $ cd /home $ ln -s .. parent $ ls parent bin boot dev etc home initrd.img lib lost+found media mnt opt proc root sbin selinux srv sys tmp usr var vmlinuz $ cd moi $ mv ../parent . $ ls parent moi $ rm parent rm*: supprimer lien symbolique «*parent*»*? o $
Oui ? Et le "dernier moment" là dedans il est où ???
Tout ce que tu montres, c'est que "parent" pointe vers "..". Et lorsque le système interprète ta commande et arrive sur "parent" ; il repart, à partir du dossier où il se trouve (comme toute interprétation des noms relatifs) sur une nouvelle interprétation mais cette fois de "..".
C'est ce que je disais déjà ici dans la description de la procédure d'accès à un fichier.
http://img29.imageshack.us/img29/8303/jzet.jpg

Accessoirement si tu crées maintenant un lien symbolique de "autre" vers "././parent" et que tu demandes un listing de "/home/moi/autre", le système analysera le chemin "/" puis "home/" puis "moi/" puis "autre". Arrivé à "autre" voyant que c'est un lien symbolique, repartira sur "./" puis "./" (oui oui, il fait deux fois l'interprétation de "."puisque le chemin en contient deux) puis "parent". Arrivé à "parent" voyant qu'il s'agit d'un lien symbolique, repartira sur "../". Il est de moins en moins question de "dernier moment" ici...

02/08/2013, 16h24
Flodelarab

Citation:

Envoyé par Sve@r

Accessoirement si tu (...) le système analysera le chemin

Voilà. Parce que c'est un lien symbolique. Si tu avais fait un lien dur vers un fichier, même avec un chemin relatif, il aurait pris l'inode et n'aurait rien analysé au dernier moment :ccool:
02/08/2013, 18h50
Sve@r

Citation:

Envoyé par Flodelarab

Voilà. Parce que c'est un lien symbolique. Si tu avais fait un lien dur vers un fichier, même avec un chemin relatif, il aurait pris l'inode et n'aurait rien analysé au dernier moment :ccool:

Ben non. Lien symbolique ou lien réel ou quoi que ce soit d'autre, dans tous les cas il prend toujours l'inode correspondant au nom qu'il est en train de traiter (voir étape 9 du schéma).
Parce que pour qu'il sache que "parent" contient "..", il est obligé d'aller chercher l'inode correspondant à "parent", vérifier les droits et le type (situés tous deux dans l'inode) et ouvrir son contenu situé dans la zone "data" du fs.
Tu vois donc bien que "dernier moment" ne veut pas dire grand chose (dernier moment de quoi ?).

Si vraiment tu veux introduire une notion temporelle dans le processus, alors c'est au moment où il analyse les caractéristiques du fichier (caractéristiques situées bien évidemment dans l'inode) qu'il se rend compte que c'est un lien symbolique et qu'il repart dans un nouveau processus de recherche de chemin tel que schématisé dans mon image (étapes 1 à 9). Mais cette notion temporelle est inutile parce qu'évidente. Les choses se passent toujours à un moment précis qui n'est pas forcément le dernier ; surtout en plus si le chemin continue après (style "/home/moi/parent/moi/./.").

Et si ce n'est pas un lien symbolique, alors au moment où il analyse les caractéristiques du fichier (moment qui est exactement le même que dans l'autre cas) puisque ce n'est pas un lien symbolique il renvoie alors le fichier vers la commande invoquée.