Le titre de ce fil était prometteur…
Savoir ce qui est pointé par un inode
mais ma question est différente:
Un fichier a plusieurs liens physiques, autrement dit, plusieurs path/noms.
Avec find /home/user/ -samefile Fichier, on obtient la réponse mais au prix d’une très longue recherche (plus de 800G de données).
L’inode étant connu, n’y aurait-il pas moyen d’accéder immédiatement à son contenu donc aux différents noms de fichier?
find . -inum inode_number
Bonjour
L’inode d’un fichier ne permet d’accéder qu’au informations concernant ce fichier,
mais pour rechercher les différents noms des chemins de fichier qui utiliseraient cet inode
il faut parcourir l’arborescence des répertoires du système de fichiers dans lequel ce fichier a été créé.
Pour accélérer la recherche, tu pourrais limiter la recherche au seul système de fichiers contenant ce fichier en utilisant l’option xdev de la commande find.
À moins de ne vouloir récupérer que ceux qui sont dans les sous-répertoires d’un chemin donné,
il vaudra mieux faire commencer la recherche à la racine (point de montage) du système de fichiers contenant le fichier.
Si c’est un système de fichiers ext*, debugfs peut trouver les chemins associés à un numéro d’inode. Mais j’ignore si c’est beaucoup plus rapide que find.
debugfs doit être exécuté avec les privilèges du compte root
J’ai d’abord créé 2 liens durs sur le fichier ~/Téléchargements/VMR6512.pdf
puis j’ai fait un test :
root@debbull:~# cheminFichier="/home/michel/Téléchargements/VMR6512.pdf"
root@debbull:~# debugfs -R 'ncheck '$(stat -c%i "$cheminFichier")'' $(df "$fileName" | awk 'NR>1 {print $1}') 2>/dev/null | awk 'NR>1 {print $2}'
/michel/Images/encoreUnAutreNomPourVMR6512.pdf
/michel/Documents/autreNomDeVMR6512.pdf
/michel/Téléchargements/VMR6512.pdf
root@debbull:~#
NOTE :
Le chemin retourné est relatif au point de montage du système de fichiers dans lequel sont le fichier et les liens durs.
Sur ma machine, les fichiers ~/Téléchargements ~/Documents et ~/Images
sont des liens symboliques vers les répertoires /michel/Téléchargements /michel/Documents et /michel/Images qui sont dans un système de fichiers différent de celui utilisé pour le système debian.
En fait, le point de montage de ce système de fichiers est /donnees/
Je ne sais pas si debugfs sera plus rapide qu’un find
pour trouver les liens durs dans le contexte où josephtux va utiliser ces lignes de commandes,
ni si il n’y a pas mieux à faire en ce qui concerne la syntaxe que j’ai utilisée
dans ma ligne de commande debugfs (c’est la première fois que j’utilise cette commande)
Je suis en train de tester sur une partition ext4 qui contient une sauvegarde incrémentale (~200Go de données).
Debugfs a trouvé les 30 liens physiques en 3 minutes, find mouline toujours…
Super !
Merci pour le retour 
Je n’avais pas de quoi tester,
alors je suis très content de voir que cette ligne de commande soit aussi efficace.
Et 40 minutes plus tard find mouline encore… 
–
Bon résultat des courses :
# time debugfs -R 'ncheck 29103259' /dev/sda1
…
real 2m50,546s
user 0m33,653s
sys 0m29,071s
# time find . -inum 29103259
…
real 57m5,340s
user 1m11,303s
sys 7m52,196s
3 minutes avec debugfs, 1 heure avec find. Il n’y pas photo.
Merci @PascalHambourg et @MicP pour avoir proposé l’utilisation de debugfs.
Bonjour,
je n’avais pas pris en compte le système de fichier. Mes données sont sur XFS.
J’ai cherché avec les outils XFS, j’ai trouvé «xfs_db » avec les options blockget n et nccheck
ainsi que la commande « xfs_ncheck -i »
mais sans résultat (sans doute n’ais-je pas compris la syntaxe)
Merci à MicP d’avoir rappelé l’option xdev que j’avais omis de signaler.
Bonjour
Une ligne de commandes récupérée dans le fil de discussion suivant
dans lequel vous trouverez la description détaillée de cette ligne de commandes
et quelques remarques concernant le système de fichiers XFS et les inodes.
et testée sur la racine de mon système debian (fs en ext4)
find / -xdev \! -type d -links +1 -printf '%20D %20i %p\n' 2>/dev/zero | sort -n | uniq -w 42 --all-repeated=separate
(Je n’avais même pas remarqué qu’il existait tous ces liens durs sur mon système.)
Ligne de commande intéressante à étudier.
(bien que je n’en vois pas bien l’utilité).
Je préfère « -type f » à « ! type d » puisque ce sont généralement ces fichiers qui sont liés (et jamais les répertoires!)
J’utilise habituellement /dev/null comme sortie et /dev/zero comme entrée. Ai-je raison ou tord?
Extrait de la description de la ligne de commandes :
…
! -type dreject directories: the.and..entries mean they’re always linked.
…
-type f ne rejette-t-il pas aussi aussi les répertoires ./ et ../ ?
Bonjour
Oui, mais pas que les répertoires :
Les liens durs vers un fichier de type lien symbolique ne seraient PAS listés.
Préparation du contexte pour les tests :
michel@debbull:~/testLiens$ touch fichierAlier
michel@debbull:~/testLiens$ ln --symbolic fichierAlier lienSymboliqueVersFichierAlier
michel@debbull:~/testLiens$ ln --physical lienSymboliqueVersFichierAlier lienDurPhysicalVerslienSymboliqueVersFichierAlier
michel@debbull:~/testLiens$ ln --logical lienSymboliqueVersFichierAlier lienDurLogicalVerslienSymboliqueVersFichierAlier
michel@debbull:~/testLiens$
michel@debbull:~/testLiens$ ls -l
total 0
-rw-r--r-- 2 michel michel 0 8 août 16:59 fichierAlier
-rw-r--r-- 2 michel michel 0 8 août 16:59 lienDurLogicalVerslienSymboliqueVersFichierAlier
lrwxrwxrwx 2 michel michel 12 8 août 17:00 lienDurPhysicalVerslienSymboliqueVersFichierAlier -> fichierAlier
lrwxrwxrwx 2 michel michel 12 8 août 17:00 lienSymboliqueVersFichierAlier -> fichierAlier
michel@debbull:~/testLiens$
Les tests :
michel@debbull:~/testLiens$ find . -xdev -type f -links +1 -printf '%20D %20i %p\n' 2>/dev/zero | sort -n | uniq -w 42 --all-repeated=separate
2069 261320 ./fichierAlier
2069 261320 ./lienDurLogicalVerslienSymboliqueVersFichierAlier
michel@debbull:~/testLiens$
michel@debbull:~/testLiens$ find . -xdev \! -type d -links +1 -printf '%20D %20i %p\n' 2>/dev/zero | sort -n | uniq -w 42 --all-repeated=separate
2069 261320 ./fichierAlier
2069 261320 ./lienDurLogicalVerslienSymboliqueVersFichierAlier
2069 262034 ./lienDurPhysicalVerslienSymboliqueVersFichierAlier
2069 262034 ./lienSymboliqueVersFichierAlier
michel@debbull:~/testLiens$
Ça fait toujours du bien de s’instruire… merci
Mais j’avoue que mon usage limité et basique de l’ordinateur ne m’avais pas encore confronté à cet usage, d’utiliser (volontairement) des liens durs sur des liens symboliques.
C’est vrai qu’il y a des fonctionnalités dont on ne voit pas du tout l’intérêt …
…et puis un jour, on se rend compte que c’est exactement ce qu’il nous faut pour résoudre un problème qu’on avait jamais rencontré avant.
Je sens que ça peut facilement devenir un piège abscons avec les liens relatifs.
Oui, mais si on était sur un système Windows,
ce genre de truc pourrait vite devenir « a new feature »