Answers:
有人建议
$ su
# umount /home
# grep -a -A800 -B800 'soldier' /dev/sda2 | strings > recovered_file
文件位于/ home文件系统中的位置上，“ home已挂载在/ dev // sda2上，而士兵”是一个关键词，可能对于覆盖的文件是唯一的。
recovery_file可能很大，但是有机会包含被覆盖文件中的文本。如果覆盖的文件主要不是文本，则此方法无用。
重要的是要采取措施防止操作系统对包含您的文件的文件系统进行进一步写入。一个好的方法是从实时CD引导。如果您可以卸载文件系统或以只读方式重新挂载它，那么就可以了。
您可能会发现，阅读http://carlo17.home.xs4all.nl/howto/undelete_ext3.html很有意思-尽管这适用于已删除的文件而不是覆盖的文件。但是，如果您以前编辑了覆盖的文件，则很自然，编辑器在磁盘上留下了几个已删除的副本，这是编辑过程的自然过程。
尽快停止使用/卸载相应的分区。
考虑这个线程，其中extundelete被提及。另外，还有photorec，foremost和scalpel，它们是非常强大的文件雕刻器，可以帮助恢复文件（例如，通过查找尚未覆盖的旧版本或文件备份）。
所有这些工具都在你的Ubuntu Apt库（可photorec自带testdisk包）。
切记将恢复结果保存在另一分区上，而不是从中恢复数据的分区上。
但是，如果您的文件确实被覆盖（例如，用于存储旧文件的硬盘上的同一区域已用于存储新文件），则无法恢复该文件（注意：仅对硬盘-ssds以另一种方式存储（和“覆盖”）文件）。如果幸运的话，您可能只能恢复未被覆盖的文件部分，例如，新文件小于旧文件。
我不认为required_file实际上已被此操作覆盖。它与相应的inode相当“未链接”，以便“消失”。some_arbit_file也不改变其位置-而是以前指向required_file的“指针”，该指针现在指向此处。
有很多工具可以在很多情况下为您提供帮助，例如Sleuthkit或Testdisk。但是它们需要一些手工工作-如果您不知道从哪里开始，那么做起来就不那么容易。还有一个名为ext3undel的脚本，它使用这些工具并自动执行该过程，或者是独立的extundelete实用程序。
无论您尝试执行什么操作：完全不触摸受影响的磁盘分区会增加恢复丢失文件的机会。最好在另一台计算机上执行所有操作，并且将受影响的驱动器以只读方式安装，即使恢复也可以提高机会。如果没有其他计算机，则可以尝试使用实时CD（请确保此处也不要以写模式安装受影响的磁盘！）。即使是LiveCD，它们也允许在内存中安装软件，因此您可以检索和运行上述任何工具。准备好其他介质（例如，记忆棒，SD卡，外部驱动器...），将恢复的文件存储到该介质，然后从那里运行该过程（无论您选择哪种方法）。