Si je démarre un processus et que j'en supprime ensuite le binaire, je peux toujours le récupérer à partir de /proc/<pid>/exe :
$ cp `which sleep` .
$ ./sleep 10m &
[1] 13728
$ rm sleep
$ readlink /proc/13728/exe
/tmp/sleep (deleted)
$ cp /proc/13728/exe ./sleep-copy
$ diff sleep-copy `which sleep` && echo not different
not different
$ stat /proc/13728/exe
File: ‘/proc/13728/exe’ -> ‘/tmp/sleep (deleted)’
Size: 0 Blocks: 0 IO Block: 1024 symbolic link
Par contre, si je fais moi-même un lien symbolique, supprime la cible et tente de copier :
cp: cannot stat ‘sleep’: No such file or directory
/proc est une interface avec le noyau. Alors ce lien symbolique pointe-t-il réellement vers la copie chargée en mémoire, mais avec un nom plus utile ? Comment fonctionne le exe le lien fonctionne, exactement ?
Réponse acceptée :
/proc/<pid>/exe ne suit pas la sémantique normale des liens symboliques. Techniquement, cela peut être considéré comme une violation de POSIX, mais /proc est un système de fichiers spécial après tout.
/proc/<pid>/exe apparaît comme un lien symbolique lorsque vous stat ce. C'est un moyen pratique pour le noyau d'exporter le chemin d'accès qu'il connaît pour l'exécutable du processus. Mais lorsque vous ouvrez réellement ce "fichier", il n'y a aucune procédure normale de lecture du contenu suivant d'un lien symbolique. Au lieu de cela, le noyau vous donne simplement accès directement à l'entrée de fichier ouverte.
Notez que lorsque vous ls -l un /proc/<pid>/exe pseudofile pour un processus dont l'exécutable a été supprimé la cible du lien symbolique a la chaîne " (supprimé)" à la fin de celui-ci. Cela n'aurait normalement aucun sens dans un lien symbolique :il n'y a certainement pas de fichier qui vit dans le chemin cible avec un nom qui se termine par " (supprimé)".
tl;dr Le proc l'implémentation du système de fichiers fait sa propre magie avec la résolution des noms de chemin.