Bonjour,
Je ne comprends pas la pharase :
busybox est situé dans /bin et init à la racine /Citation:
Il faut créer un lien symbolique de busybox vers /init.
ouCode:
1
2 ln -s sbin/busybox init
ou autre chose encore?Code:ln -s init sbin/busybox
Version imprimable
Bonjour,
Je ne comprends pas la pharase :
busybox est situé dans /bin et init à la racine /Citation:
Il faut créer un lien symbolique de busybox vers /init.
ouCode:
1
2 ln -s sbin/busybox init
ou autre chose encore?Code:ln -s init sbin/busybox
Bonjour,
:DCode:
1
2
3 ln --help Utilisation*: ln [OPTION]... [-T] TARGET LINK_NAME (1er format) [...]
un peu de contexte, pour comprendre la directive
...
?
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?
Bonjour,
j'utilise comme moyen mnémotechnique que les arguments de 'ln' sont dans le même sens que ceux de 'cp'.
Donc:
et, de même:Code:cp 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?Code:ln -s truc_qui_existe vers_cible_qui_n_existe_pas_encore
Si /sbin/busybox existe déjà, mais pas encore /init alors c'est:
Si /init existe déjà, mais pas encore /sbin/busybox alors c'est:Code:ln -s /sbin/busybox /init
Code:ln -s /init /sbin/busybox
Pas mal ton moyen mnémotechnique. Je me trompe une fois sur deux avec cette commande (car je l'utilise rarement)
Merci pour la réponse détaillée. C'est vrai que ce moyen mémo-technique est efficace.
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.
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
Je pige pas trop cette phrase. Le système n'obéit qu'aux ordres que je lui demande...
"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...
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...
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é
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.
Plus exactement quand le compteur de liens (situé dans l'inode) tombe à 0.
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.
Séquence (nf): suite ordonnée. Il n'est nullement question de temps dans cette définition (ni dans aucune autre de ses synonymes).
Moui, comme tout nom relatif...
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 $
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...
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.