从内存中恢复Python脚本，我搞砸了

Question

救命，我搞砸了。

我有一个比较复杂的python脚本，它当前运行在Ubuntu服务器的putty窗口中。

我不小心用另一个putty窗口重写了脚本，所以硬盘上的副本现在不见了，但脚本仍在第一个窗口的内存中运行。

这是在我有机会运行此文件夹的备份之前发生的。

有没有办法从第一个putty窗口的内存中获取脚本（当前正在运行）？

我没有停止剧本，我猜一旦我停止它将永远消失。

我能把它以某种方式发送到后台进程（一些热键），然后从内存转储或其他地方收集脚本吗。我假设这样的事情必须在脚本运行的实际窗口中发生。

如果我能把.py弄回来就好了，我听说Python在运行之前会编译这个脚本，如果是这样的话，人类可读的部分可能就不见了。

唉，这一天压力很大。

谢谢你的帮助，马克

Answer 1

对于这个问题，我已经晚了两年，但这就是我恢复剧本的方法。 运行脚本后，在pycache文件夹中，将有与脚本同名的.pyc（字节码）文件。您可以使用名为uncompyle的第三方模块来反编译此.pyc文件以获取源代码。唯一的缺点是你的评论会丢失。但总比什么都没有好。

Answer 2

这是一个迟来的答案，但是对于每个使用IDE eclipse的人（其他人也有类似的东西），都可以使用eclipse历史轻松地恢复他们的*.py或其他文件。 eclipse文档中的更多内容： https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-87b.htm 或者更好： Eclipse, recover recent history

Answer 3

据我所知，Python并没有将源代码保存在内存中，注释中提供的方法只保留可执行文件，而不是脚本。转储程序的内存可能允许您获取字节码，但我不知道这可能需要多少努力。

相反，我将首先尝试一种非特定于Python的方法，这种方法成功地用于恢复意外删除的Python源代码。这假设文件系统是ext2/3/4，并且您具有根访问权限。

第一步（在任何恢复中）显然是尽量避免在系统上写入任何文件，以免覆盖您正在查找的数据。在主系统上，如果可能的话，我可能会亲自将分区重新装载为只读，以避免再发生任何写操作。我听说其他人建议快速拔掉插头，这可能会阻止操作系统/磁盘缓存写入磁盘，如果您真的很快就可以保存一些额外的数据（甚至防止删除）。在远程系统上，这两种方法都不是一个好主意（除非数据非常重要，而且您可以将磁盘发送给您或其他人），因为如果某个东西突然变成只读的，系统可能不喜欢它。

第二步是执行debugfs /dev/sdXY，其中/dev/sdXY是已删除文件所在的分区。在提示中，说blocks /path/to/the/directory/the/removed/file/was/in。然后，给出指向目录中其他现有文件的blocks命令路径。现在，通过说quit退出程序，并希望看到的块编号彼此接近。如果目录是旧的并且块编号分散，请从最近文件的块编号开始。（也就是说，最后一次修改的文件与被删除文件的最后一次修改时间尽可能接近）我们将尝试在假定文件存储在靠近它们的位置的情况下，扫描目录中其他文件附近的分区的内容。执行dd if=/dev/sdXY bs=4096 skip=BLOCKNUMBER count=COUNT |grep -C APPROXIMATE_LINE_COUNT_OF_THE_REMOVED_FILE WORD，其中BLOCKNUMBER是第一个块号之前的某个数字，COUNT是要搜索的适当块数，WORD是包含在源文件中的单词。如果你什么都没有，试着在另一个文件块附近钓鱼。如果时间不是问题，您可以考虑只在删除的文件中出现的字符串（这样您就不会得到太多的误报），您可以跳过所有这些，用grep -a WORD -C LINECOUNT /dev/sdXY扫描整个磁盘。

另一种方法（你应该先试另一种方法）可能对你不起作用，因为IIRC最新版本的Ubuntu（可能还有其他系统）在默认情况下将内核配置为阻止对/dev/mem的访问，正在尝试扫描内存中的文件。只需grep -a WORD -C LINECOUNT /dev/mem扫描内存而不是分区。（如果您在表单域中编写了长文本，并且您错误地单击，而您的浏览器清空了该域，则这也可以节省您的时间）