Help, I screwed up.
I have a somewhat complex python script that is currently running in a putty window to a Ubuntu server.
I accidentally overwrote the script using another putty window, so the copy on the hard drive is now gone, but the script is still running from memory in the first window.
This happened before I had a chance to run my backups for this folder.
Is there a way I can get the script, (that is currently running) from the memory in the first putty window?
I haven't stopped the script, my guess is once I stop it it will be gone forever.
Can I send it to a background process somehow (some hot key,) then glean the script from a memory dump or something. I assume something like this would have to happen from the actual window from which the script is running.
It would be nice if I could get the .py back, I heard Python compiles the script before running, if that is the case, the human readable part may be gone.
Sigh, it has been a stressful day.
Thanks for any help, Mark.using
As far as I know, Python doesn't keep the source in memory, and the method presented in the comment only keeps executables alive, not scripts. Dumping the memory of the program probably allows you to get to the bytecode, but I have no idea how much effort that might require.
Instead, I'd first try a non-Python-specific approach that I've succesfully used to recover Python sources that I've accidentally deleted. This assumes the filesystem is ext2/3/4 and that you have root access.
The first step (in any recovery) is obviously to try to avoid writing any files on the system so as to not overwrite the data that you are looking for. On a home system I'd probably personally remount the partition as read-only if possible to avoid any more writes going through. I've heard other people recommend just quickly pulling the plug, which might prevent the OS/disk cache from being written to the disk and perhaps save you some additional data (or even prevent the deletion) if you're really quick about it. On a remote system, neither of these is probably a good idea (unless the data is really important and you can get the disk shipped to you or something) since the system might not like it if something goes read-only all of a sudden.
The second step is to execute debugfs /dev/sdXY, where /dev/sdXY is the partition that the deleted file was on. In the prompt, say blocks /path/to/the/directory/the/removed/file/was/in. Then, give the blocks command paths to other existing files in the directory. Now, exit the program by saying quit, and hope that the block numbers you saw were close to each other. If the directory is old and the block numbers scattered, start with a recent file's block numbers. (That is, one that has been last modified as close in time to the removed file's last modification time as possible) We will try to scan the contents of the partition near the other files in the directory under the assumption that the files was stored close to them. Execute dd if=/dev/sdXY bs=4096 skip=BLOCKNUMBER count=COUNT |grep -C APPROXIMATE_LINE_COUNT_OF_THE_REMOVED_FILE WORD, where BLOCKNUMBER is a number somewhere before the first block number, COUNT is some suitable number of blocks to search and WORD is a word that was contained in the source file. If you don't get anything, try fishing near another file's blocks. If time is not an issue, and you can think of a string that only occurred in the removed file (so you don't get too many false positives), you might just skip all that and scan the whole disk with grep -a WORD -C LINECOUNT /dev/sdXY.
Another method (that you should try before the other one) that probably won't work for you since IIRC recent versions of Ubuntu (and probably other systems too) by default configure the kernel to block access to /dev/mem, is trying to scan the memory for the file. Just do grep -a WORD -C LINECOUNT /dev/mem to scan memory instead of the partition. (This can also save your day if you've written a long text in a form field and you misclick and your browser empties the field)