我在命令行上完成了此操作(Ubuntu 12.04,ext4)
mv some_arbit_file required_file
有什么方法可以恢复 required_file 吗?我为此付出了很多努力。我通常会备份文件,但这次我忘了。
答案1
有人建议
su
umount /home
grep -a -A800 -B800 'target' /dev/sda2 | strings > recovered_file
这些行假设您的文件位于/home
文件系统中,/home
已安装在分区上/dev/sda2
,并且“target”是可能对覆盖文件唯一的关键短语。该选项-a
将所有二进制文件作为文本文档处理,选项-A800
和-B800
显示与“target”匹配前后的 800 行。
该命令strings
提取来自 grep 的标记流的文本文件。如果您使用的是实时 USB,则此命令可能不可用,但您仍然应该能够从存储库中安装它。
recovered_file
可能很大,但有可能包含被覆盖文件中的文本。如果被覆盖文件的主要内容不是文本,则此方法无效。
采取措施防止操作系统进一步写入包含您的文件的文件系统非常重要。一个好方法是从实时 CD/USB 启动。如果您可以卸载文件系统或以只读方式重新挂载它,那也是不错的选择。
你可能会发现阅读它很有趣http://carlo17.home.xs4all.nl/howto/undelete_ext3.html- 虽然这更多地适用于已删除的文件,而不是已覆盖的文件。但是,如果您之前编辑过已覆盖的文件,那么编辑人员很可能会将几个已删除的副本留在磁盘上,这是编辑过程的自然组成部分。
答案2
答案3
我不认为 required_file 实际上被此操作覆盖了。它只是从相应的 inode 中“断开链接”以便“消失”。some_arbit_file 也没有改变它的位置——而是之前指向 required_file 的“指针”现在指向了这里。
有一些工具可以帮助你解决这种情况,例如侦探工具或者测试盘。但它们需要一些手动工作——如果你不知道从哪里开始,那就不那么容易了。还有一个脚本叫做ext3undel使用这些工具并自动化流程,或独立的删除公用事业。
无论您尝试做什么:完全不触碰受影响的磁盘分区都会增加您恢复丢失文件的机会。最好在另一台机器上执行所有操作,并且即使是为了恢复也以只读方式安装受影响的驱动器也会增加您的机会。如果没有其他机器,您可以尝试使用 Live CD(确保不要在此处以写入模式安装受影响的磁盘!)。即使是 LiveCD,它们也允许在内存中安装软件,因此您可以检索和运行上述任何工具。手边准备一个额外的介质(例如记忆棒、SD 卡、外部驱动器……)来存储您恢复的文件,然后从那里运行该过程 - 无论您选择哪种。