... mieux que de copier à un moment donné (et de ne rassembler que l'instantané du contenu du fichier à ce moment-là) est de "tail -f " ce fichier dans un nouveau fichier :
tail -c +0 -f /proc/PIDofProgram>/fd/# > /new/path/to/file
(grâce aux programmeurs prudents de tail, cela fonctionnera même avec une sortie binaire.)
Lors de son exécution, le tail -f lui-même garde le fichier ouvert, l'empêchant en toute sécurité d'être purgé du disque lorsque le programme d'origine se termine. Ainsi, n'arrêtez pas le tail -f immédiatement après la fin de votre programme d'origine - vérifiez le /new/path/to/file suivi d'abord si c'est l'est ce que tu veux. Si ce n'est pas le cas (ou s'il n'est pas satisfaisant pour toute autre raison), vous pouvez copier à nouveau le fichier d'origine, mais cette fois après toute écriture s'est terminée par "Program" et à partir du tail -f toujours en cours d'exécution du répertoire /proc/PIDoftail/fd/.
Si /home est NFS, il y aura un fichier .nfsNNNNNNNNNN dans /home/vi auquel vous pourrez accéder/copier. Si home est un système de fichiers local, vous devriez pouvoir faire la même chose via le lien /proc/PID/fd/3 :
cp /proc/PID/fd/3 /tmp/recovered_file
Si vous souhaitez réellement restaurer le fichier, voici un article de blog sur le sujet.
Utilisez lsof pour trouver le numéro d'inode et debugfs pour recréer un lien physique vers celui-ci. Par exemple :
# lsof -p 12345 | grep /var/log/messages
syslogd 12345 root 3w REG 8,3 3000 987654 /var/log/messages (deleted)
# mount | grep var
/dev/sda2 on /var type ext3 (rw)
# debugfs -w /dev/sda2
debugfs: cd log
debugfs: ln <987654> tmp
debugfs: mi tmp
Mode [0100600]
User ID [0]
Group ID [0]
Size [3181271]
Creation time [1375916400]
Modification time [1375916322]
Access time [1375939901]
Deletion time [9601027] 0
Link count [0] 1
Block count [6232]
File flags [0x0]
...snip...
debugfs: q
# mv /var/log/tmp /var/log/messages
# ls -al /var/log/messages
-rw------- 0 root root 3301 Aug 8 10:10 /var/log/messages
Avant que vous ne vous plaigniez, j'ai truqué la transcription ci-dessus car je n'ai pas de fichier supprimé à portée de main pour le moment ;-)
J'utilise mi pour réinitialiser le temps de suppression et le nombre de liens à des valeurs sensibles (0 et 1 respectivement), mais cela ne fonctionne pas correctement - vous pouvez voir que le nombre de liens reste à zéro dans ls . Je pense que le noyau pourrait mettre en cache les données d'inode. Vous devriez probablement fsck dès que possible après avoir utilisé debugfs, pour être du bon côté.
D'après mon expérience, vous devez créer le lien en utilisant un nom de fichier temporaire, puis le renommer avec le nom approprié. Le lier directement au nom de fichier d'origine semble provoquer une corruption du répertoire. YMMV !
- http://glandium.org/blog/?p=87
- http://www.cyberciti.biz/tips/linux-ext3-ext4-deleted-files-recovery-howto.html