Используйте lsof, чтобы найти номер инода, и debugfs, чтобы воссоздать жесткую ссылку на него. Например:
# 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
Прежде чем жаловаться, я фальсифицировал приведенную выше стенограмму, так как у меня нет удаленного файла, который можно передать сейчас ;-)
Я использую mi
для сброса времени удаления и количества ссылок на разумные значения (0 и 1 соответственно), но это не работает должным образом - вы можете видеть, что количество ссылок остается на нуле ls
. Я думаю, что ядро может кэшировать данные inode. Вероятно, вы должны использовать fsck при первой же возможности после использования debugfs, чтобы быть в безопасности.
По моему опыту, вы должны создать ссылку, используя временное имя файла, а затем переименовать в правильное имя. Связывание его непосредственно с исходным именем файла может привести к повреждению каталога. YMMV!
readlink /proc/13381/fd/3
-> "/ home / vi / важный_файл (удалено)" и,/home/vi/important_file\ \(deleted\)
очевидно, не существует.