我错误地在创建了许多 c 程序文件的当前目录上运行了 rm * 。我从早上就开始研究这些。现在我不能再抽出从早上开始创建文件的时间了。请说一下如何恢复。它们也不在回收站!
答案1
如果正在运行的程序仍然打开已删除的文件,则可以通过 中的打开文件描述符恢复该文件/proc/[pid]/fd/[num]
。要确定是否属于这种情况,您可以尝试以下操作:
$ lsof | grep "/path/to/file"
如果上面给出了以下形式的输出:
progname 5383 user 22r REG 8,1 16791251 265368 /path/to/file
记下第二列中的 PID 和第四列中的文件描述符编号。使用此信息,您可以通过发出以下命令来恢复文件:
$ cp /proc/5383/fd/22 /path/to/restored/file
如果您无法找到带有 的文件lsof
,您应该立即重新挂载包含该文件的只读文件系统:
$ mount -o remount,ro /dev/[partition]
或完全卸载文件系统:
$ umount /dev/[partition]
这样做的原因是,一旦文件被取消链接,并且不存在指向该文件的剩余硬链接,底层文件系统可能会释放先前为已删除文件分配的块,此时这些块可能会被删除。分配给另一个文件并覆盖其内容。因此,如果要进行任何恢复,停止对文件系统的任何进一步写入对于时间至关重要。如果文件系统是根文件系统或者由于某些其他原因无法变为只读或卸载,则可能需要关闭系统(如果可能)并从可以保留目标文件的实时环境中继续恢复系统只读。
在阻止对文件系统的写入后,不必立即急于尝试实际恢复。为了安全起见,您可能需要备份文件系统以在以下位置执行实际恢复:
$ dd bs=4M if=/dev/[partition] of=/path/to/backup
接下来的步骤现在取决于文件系统类型。假设典型的 Ubuntu 安装,您很可能有一个ext3
或ext4
文件系统。在这种情况下,您可以尝试使用恢复extundelete
。只要未安装(或以只读方式安装),就可以在备份或原始设备上安全地尝试恢复。不要尝试从活动文件系统恢复。这很可能会使文件系统陷入不一致的状态。
extundelete
将尝试将它找到的任何文件恢复到名为 的当前目录的子目录中RECOVERED_FILES
。从备份恢复所有已删除文件的典型用法是:
对于旧版本:
$ extundelete /path/to/backup --restore-all
对于较新的版本(例如 0.2.4),不要安装您尝试恢复的设备(感谢 Ryan Lue):
$ extundelete /dev/<device-file> --restore-all
--restore-all
您可以尝试使用--restore-file <path>
或 之类的选项来代替--restore-directory <path>
答案2
是的,我能够恢复我的文件。我还没有检查是否全部恢复,但我检查过的一些已经恢复。由于有很多文件是通过该工具/命令恢复的,因此我需要在这些文件中 grep 一些文本模式并查看哪些是我的。文件以不同的名称恢复(可能由系统生成)。我从另一个论坛得到了解决方案,命令是 photorec
sudo photorec
这将打开一个基于文本的窗口。我按照说明进行操作,是的,非常棒。