Forum Linux.débutant création liens symboliques impossible

Posté par jean45 le 21 décembre 2019 à 10:31. Licence CC By‑SA.

Étiquettes :

déc.

2019

Bonjour,

situation:
sous Linux mint, j'essaie de créer des liens symboliques de mes images pour pouvoir les classer ensuite dans plusieurs dossiers, et éviter de dupliquer les fichiers, pour gagner de la place mémoire.

problème:
dans un dossier ou j'ai plusieurs images, je crée un sous-dossier "test", et je tape dans le terminal du dossier où se trouve les images:
"ln -sv * test"
Tout semble bien se passer, mais quand je vais dans le dossier "test" tous les liens sont cassés (inexploitables)

Que faire ?
Merci

# chemin relatif / absolu

Posté par gaaaaaAab le 21 décembre 2019 à 12:23. Évalué à 4.
ce que tu fais doit un peu ressembler à ça:
```
$ mkdir -p exemple/test
$ cd exemple
$ touch fichier
$ ln -s * test
$ ls -l test
total 0
lrwxrwxrwx 1 gab gab 7 Dec 21 12:00 fichier -> fichier
lrwxrwxrwx 1 gab gab 4 Dec 21 12:00 test -> test
```
et ça produit effectivement des liens cassés. Au passage, tu noteras que tu as un lien cassé vers le répertoire lui-même, ce qui pourrait être un problème. Ça serait bien d'être plus précis sur le * pour éviter ça.

La raison de ton problème est que si la cible est un chemin relatif, ln produit un lien symbolique avec un chemin relatif. Avec tes arguments actuels, ln produit un lien symbolique vers des fichiers dans le dossier local, mais les fabrique dans un répertoire d'un autre niveau, et c'est le drame.
Je sais, c'est pas très clair, alors encore un peu de code:
```
$ mkdir -p exemple/test
$ cd exemple
$ touch fichier
$ ls ../fichier
ls: cannot access '../fichier': No such file or directory
$ ln -s ../fichier test
$ ls -l test/
total 0
lrwxrwxrwx 1 gab gab 10 Dec 21 12:06 fichier -> ../fichier
```
Et là, c'est un lien pas cassé. Mais c'est pas une super méthode. Pour créer des liens relatifs corrects, tu peux aussi ajouter l'option -r de ln (que j'ai découvert en lisant le man pour te répondre ;) ), ou, ce que j'ai tendance à faire, appeler ln, mais depuis le répertoire de destination:
```
$ mkdir -p exemple/test
$ cd exemple
$ touch fichier
$ cd test
$ ln -s ../fichier .
$ ls -l
total 0
lrwxrwxrwx 1 gab gab 10 Dec 21 12:15 fichier -> ../fichier
```
Tu peux aussi créer des liens symboliques avec des chemins absolus.
```
$ mkdir -p exemple/test
$ cd exemple
$ touch fichier
$ ln -s ~/exemple/fichier test
$ ls -l
ls -l
total 0
lrwxrwxrwx 1 gab gab 25 Dec 21 12:18 fichier -> /home/gab/exemple/fichier
```
Chemins relatifs et absolus ont leurs avantages et inconvénients. Le plus adapté va complètement dépendre de ton usage. Si tu restes dans l'optique d'un sous-répertoire de travail dans ton répertoires de photos, les liens relatifs, ça ira probablement très bien.
- [^] # Re: chemin relatif / absolu
  
  Posté par jean45 le 22 décembre 2019 à 15:27. Évalué à 1.
  
  merci de votre réponse documentée.
  Il faut le temps que je regarde en détail.
  Mais il me semble que la bonne idée, c'est de prendre des chemins absolus
  
  nb: je ne savais pas très bien faire la différence entre chemin relatifs et absolus. Mais effectivement j'avais remarqué qu'en déplaçant mes liens symboliques, ils ne pointaient plus vers le fichier d'origine où se trouvait mes photos, la catastrophe pour mon usage.
  (en fait je cherche un usage similaire à celui des raccourcis de Windows que j'avais utilisé abondamment)
# Liens durs

Posté par Axone le 23 décembre 2019 à 07:18. Évalué à 5.

Et pourquoi pas des liens durs qui m'ont l'air plus appropriés pour ton usage.

Pour ton exemple, tu fais :
cp --link * test/
et tu auras une copie de tes fichiers du répertoire courant dans le sous répertoire test.

Cette copie en lien dur ne prendra pas plus de stockage, car les fichiers dupliqués pointent sur l'inode du fichier original. Tu peux faire ls -i pour voir les numéros d'inode et un ls -l pour voir pour un fichier le nombre d'exemplaire qui se trouve sur ton disque dur.
- [^] # Re: Liens durs
  
  Posté par jean45 le 24 décembre 2019 à 08:16. Évalué à 2.
  
  "Cette copie en lien dur ne prendra pas plus de stockage, car les fichiers dupliqués pointent sur l'inode du fichier original."
  est-ce bien vrai ?
  
  Quand je demande la taille du fichier du "lien dur", il m'indique la taille du fichier d'origine.
  Comment puis-je vérifier qu'il est bien "plus petit" que l'original ?
  
  Merci de cette réponse qui serait idéale pour moi.
  
  nb: je doute que la taille soit plus petite, car si je supprime le fichier de départ , j'ai toujours accès au fichier à partir du "lien dur"
  - [^] # Re: Liens durs
    
    Posté par Benoît Sibaud (site web personnel) le 24 décembre 2019 à 09:16. Évalué à 4.
    
    Un fichier c'est de base une inode (soit 1 kiB, 2 kiB, 4 kiB, etc suivant les cas) plus la taille du fichier.
    Si on copie le fichier, ça coûte deux inodes et deux fois la taille.
    Si on lie le fichier (lien dur ou lien symbolique), ça coûte deux inodes et une fois la taille.
    
    La taille renvoyée sur le lien dur ou symbolique est par défaut celle du fichier lié.
  - [^] # Re: Liens durs
    
    Posté par Axone le 24 décembre 2019 à 10:20. Évalué à 3.
    Dans un répertoire nommé tmp/, j'ai mis un fichier image (image1.jpg) que j'ai ensuite copié par lien dur (cp --link image1.jpg image2.jpg).
    Un ls -lih, me donne :
```
906564 -rwxrwxrwx 2 denis users 9,4M 23 janv.  2019 image1.jpg
906564 -rwxrwxrwx 2 denis users 9,4M 23 janv.  2019 image2.jpg
```
    Les fichiers partagent bien le même inode.
    
    Ensuite je remonte d'un répertoire, puis je fais un du -sh tmp/ pour examiner la taille du répertoire. Cela me donne :
```
9,4M    tmp/
```
    Une copie normale aurait donné 18,8M d'espace occupé.
    - [^] # umask ?
      
      Posté par Arthur Accroc le 24 décembre 2019 à 13:11. Évalué à 3.
      Un ls -lih, me donne :
      
      906564 -rwxrwxrwx 2 denis users 9,4M 23 janv. 2019 image1.jpg 906564 -rwxrwxrwx 2 denis users 9,4M 23 janv. 2019 image2.jpg
      
      Tu crées tes fichiers par défaut avec les droits de lecture et d’écriture pour tout le monde ?
      Bon, c’est peut-être ton support photo que tu montes comme ça et après les fichiers copiés en préservant les droits. Ce serait moins ennuyeux, mais pas tout à fait idéal quand même.
      
      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
    - [^] # Re: Liens durs
      
      Posté par jean45 le 25 décembre 2019 à 22:46. Évalué à 2.
      
      je ne suis pas suffisamment expérimenté, et vous semblez sûr que le lien en dur ne prend pas autant de place qu'une copie.
      
      Mais alors, comment expliquez vous que si je supprime ma photo initiale, et que je clique sur le lien en dur, j'obtiens toujours la photo ?
      
      L'explication la plus simple serait que "quelque part" le fichier de la photo soit dupliqué, et donc que je ne gagne rien en place mémoire par rapport à une copie.
      
      nb: on pourrait imaginer qu'au moment ou je supprime l'image de départ, il se crée alors une copie si j'ai créé un lien en dur sur cette photo.
      Difficile à croire, mais possible …
      - [^] # Re: Liens durs
        
        Posté par Arthur Accroc le 26 décembre 2019 à 14:43. Évalué à 4.
        
        L'explication la plus simple serait que "quelque part" le fichier de la photo soit dupliqué, et donc que je ne gagne rien en place mémoire par rapport à une copie.
        
        Non, en quelque sorte tout fichier est déjà un lien dur vers ses données, c’est-à-dire un inode qui pointe dessus.
        Si tu crées un lien dur avec ln (sans l’option -s) ou cp -l, c’est juste un deuxième inode, tout-à-fait similaire au premier, qui pointe vers les mêmes données.
        Dans la commande ln, tu indiques un fichier (donc un inode) comme source du lien dur, mais en fait le système va voir où sont les données et crée un nouvel inode qui pointe directement dessus (cp -l fonctionne sur le même principe, mais avec des possibilités supplémentaires comme de descendre dans les sous-répertoires).
        
        Ce serait mieux avec un schéma (quand j’ai eu l’explication il y a longtemps, j’ai eu droit à un schéma), mais je ne me sens pas trop de faire de l’ASCII art… Imagine des petits carrés identiques (les inodes) avec chacun une flèche qui partent des carrés et vont vers le même grand rectangle (les données). Quand tu crées ton fichier, tu as un petit carré et une flèche ; à chaque fois que tu fais un lien dur, tu ajoutes un petit carré avec une nouvelle flèche pointant directement vers le rectangle des données, comme celle du premier petit carré.
        
        Quand tu fais un ls -l, le nombre que tu vois avant le nom du propriétaire du fichier, c’est le nombre d’inodes qui pointent sur ses données (de flèches qui pointent le grand rectangle).
        En général, pour un fichier, c’est 1… sauf si tu as utilisé ln ou cp -l pour faire un voire plusieurs liens durs.
        
        Quand tu supprimes un fichier, que ce soit le fichier d’origine ou un lien dur créé avec ln ou cp -l, le système supprime son inode (le petit carré et la flèche) et décrémente leur nombre pour les données pointées. Seulement si ce nombre arrive à 0 (plus aucune flèche vers le grand rectangle), les données sont supprimées. Que ce soit l’inode d’origine ou pas n’a pas d’influence sur le traitement effectué.
        
        À noter toutefois que les liens durs ne sont possibles que dans une même partition : un inode ne peut pas pointer vers des données situées dans une autre partition.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: Liens durs
        
        Posté par jean45 le 26 décembre 2019 à 16:10. Évalué à 2.
        
        merci beaucoup pour cette explication qui me paraît satisfaisante.
        
        merci aussi de votre patience pour un débutant
        
        [^] # Re: Liens durs
        
        Posté par wismerhill le 26 décembre 2019 à 16:33. Évalué à 6.
        
        Si tu crées un lien dur avec ln (sans l’option -s) ou cp -l, c’est juste un deuxième inode, tout-à-fait similaire au premier, qui pointe vers les mêmes données.
        
        Correction: il n'y a qu'un seul inode, c'est lui le point d'entrée vers les données (tu peux vérifier avec ls -i qui te donne le numéro de l'inode).
        Ensuite, il peut y avoir un certain nombre de noms (dans n'importe quel répertoire du même système de fichier) qui pointent vers cet inode.
        L'inode lui-même contient un compteur⁽¹⁾ du nombre de liens physique qui pointent vers lui.
        
        Supprimer un fichier consiste en fait à supprimer le nom dans le répertoire correspondant et décrémenter le compteur de liens dans l'inode.
        Si le compteur tombe à zéro (et que plus aucun programme n'utilise l'inode⁽²⁾), alors seulement l'inode, et toutes les donnés associées, sont libérés.
        
        ⁽¹⁾ c'est le champ "link count" dans la page de manuel "inode"
        ⁽²⁾ c'est pour ça que, dans certains cas (typiquement un fichier de log), l'espace du fichier n'est pas tout de suite rendu
        
        [^] # Re: Liens durs
        
        Posté par Arthur Accroc le 26 décembre 2019 à 17:26. Évalué à 3.
        
        Correction: il n'y a qu'un seul inode, c'est lui le point d'entrée vers les données (tu peux vérifier avec ls -i qui te donne le numéro de l'inode).
        
        Tu as raison, il faut croire que je suis un peu rouillé là-dessus.
        
        Bonne nouvelle pour jean45, le principal reste valable : les données ne sont pas dupliquées par un lien dur, elles ne sont effacées que quand plus rien ne pointe dessus (indépendamment du fait qu’on commence par supprimer un lien dur ou le fichier d’origine) et restent accessibles tant que ce n’est pas le cas.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
  - [^] # Attention quand même
    
    Posté par Arthur Accroc le 24 décembre 2019 à 13:06. Évalué à 4.
    
    Comme l’ont expliqué Benoît et Axone, le contenu du fichier n’est pas dupliqué, tu as juste deux inodes qui pointent dessus.
    
    Par contre, attention en cas de copie (par exemple pour sauvegarde), à ce que le programme utilisé préserve bien les liens durs, sinon la taille de la copie va doubler !
    
    cp le fait par défaut, mais rsync nécessite l’option -H
    
    À d’autres niveaux, c’est plus souple que les liens symboliques. Par exemple, aucun problème si tu déplaces l’un des deux répertoires. À noter quand même que si tu déplaces l’un des deux sur un autre volume ou une autre partition, tu auras deux copies.
    
    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
    - [^] # Re: Attention quand même
      
      Posté par Arthur Accroc le 24 décembre 2019 à 13:18. Évalué à 3.
      
      cp le fait par défaut
      
      En fait non, il faut à minima l’option --preserve=links
      Elle est incluse dans les options -d et -a (que j’utilise quasiment tout le temps, ce qui explique pourquoi j’ai cru qu’il le faisait par défaut).
      
      Note : il est bien pénible Gandalf, à empêcher de corriger ce qu’on a écrit.
      
      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# liens symboliques vs hard

Posté par guitou le 26 décembre 2019 à 17:06. Évalué à 2. Dernière modification le 27 décembre 2019 à 14:45.
Bonjour à tous, et joyeux (lendemain de) Noël accessoirement.
Me sentant d'humeur à faire mon ch… aujourd'hui je vais apporter mon grain de sel à l'eau de ce moulin (gné ?).

Un fichier, c'est un inode et une entrée dans la table d'allocation pour en préciser le chemin (entre autres…).
Un hardlink, c'est une entrée supplémentaire dans la table pointant vers un inode (bref, un chemin alternatif vers le même inode).
Un softlink est un fichier spécial (et donc aussi une entrée dans la table d'allocation) indiquant une redirection vers un autre fichier (et plutôt même, de fait, un chemin de fichier).

Les implications:
Les hardlinks sont limités à un même filesystem, et peu importe d'indiquer un chemin absolu ou relatif, au final c'est l'inode qui fait autorité.
Les softlinks peuvent pointer vers un autre filesystem, par contre il incombe à l'utilisateur de s'assurer du maintien du fichier ciblé.

Petit exercice pratique pour illustrer le propos:
```
mkdir testdir
cd testdir
touch fichier
ln fichier lienhard
ln -s fichier liensoft
    # joujou avec ls et options -l et -i notamment pour constater que fichier et lienhard partagent le même inode
rm fichier
    # re-joujou avec ls pour constater que notre symlink est cassé et que le fichier, bien qu'absent sous ce nom, est toujours accessible via le hardlink créé auparavant
```
The détail qui tue et que mon pauvre petit neurone souvent poussif a mis fort longtemps à intégrer (d'où mon inclination à le mettre ici en exergue): dans le cas d'un lien hard, si l'on indique un chemin relatif, la référence est le répertoire courant alors que pour un lien soft, c'est l'emplacement du lien. Illustration:
```
    # on est toujours dans testdir
touch fichier # si on ne recrée pas le fichier précédemment effacé, l'exemple n'est plus valable
mkdir subdir
ln fichier subdir/poettering # petite touche d'humour glacé et sophisiqué dont le sens m'échappe tout autant qu'à vous, mais toujours est-il que ça marche
ln -s fichier subdir/autreliensoft # oops, broken link
ln -s ../fichier subdir/autreliensoft # cette fois c'est la bonne (à moins qu'il ne faille user aussi de l'option -f puisque le lien existe déjà, tout cassé soit-il, j'avoue ne pas faire le test en direct moi-même... mea culpa, mea gross culpa !)
```
Amicalement,
++
Gi)
- [^] # Re: liens symboliques vs hard
  
  Posté par NeoX le 27 décembre 2019 à 14:45. Évalué à 2.
  
  edition pour mise en page avec les balises de codes indiquées en bas de page,
  afin de rendre la partie code plus lisible par rapport à la partie texte.
  
  :p

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.