By mistake I ran rm * on the current directory where I created many c program files. I had been working on these since morning. Now I can't take out again the time that I spent since morning on creating the files. Please say how to recover. They aren't in recycle bin also!
2 Answers
If a running program still has the deleted file open, you can recover the file through the open file descriptor in /proc/[pid]/fd/[num]
. To determine if this is the case, you can attempt the following:
$ lsof | grep "/path/to/file"
If the above gives output of the form:
progname 5383 user 22r REG 8,1 16791251 265368 /path/to/file
take note of the PID in the second column, and the file descriptor number in the fourth column. Using this information you can recover the file by issuing the command:
$ cp /proc/5383/fd/22 /path/to/restored/file
If you're not able to find the file with lsof
, you should immediately remount the file system which housed the file read-only:
$ mount -o remount,ro /dev/[partition]
or unmount the file system altogether:
$ umount /dev/[partition]
The reason for this is that as soon as the file has been unlinked, and there are no remaining hard links to the file in question, the underlying file system may free the blocks previously allocated for the deleted file, at which point the blocks may be allocated to another file and their contents overwritten. Ceasing any further writes to the file system is therefore time critical if any recovery is to be possible. If the file system is the root file system or cannot be made read-only or unmounted for some other reason, it might be necessary to shutdown the system (if possible) and continue the recovery from a live environment where you can leave the target file system read-only.
After writes to the file system have been prevented, there is no immediate hurry to attempt the actual recovery. To play it safe, you might want to make a backup of the file system to perform the actual recovery on:
$ dd bs=4M if=/dev/[partition] of=/path/to/backup
The next steps now depend on the file system type. Assuming a typical Ubuntu installation, you most likely have a ext3
or ext4
file system. In this case, you may attempt recovery using extundelete
. Recovery may be attempted safely on either the backup, or the raw device, as long as it is not mounted (or it is mounted read-only). DO NOT ATTEMPT RECOVERY FROM A LIVE FILE SYSTEM. This will most likely bring the file system to an inconsistent state.
extundelete
will attempt restore any files it finds to a subdirectory of the current directory named RECOVERED_FILES
. Typical usage to restore all deleted files from a backup would be:
With older versions:
$ extundelete /path/to/backup --restore-all
With newer versions (e.g. 0.2.4), don't mount the device you're trying to recover from (thanks to Ryan Lue) :
$ extundelete /dev/<device-file> --restore-all
Instead of --restore-all
, you can try options like --restore-file <path>
or --restore-directory <path>
-
Note for anyone using a recent version of
extundelete
: the CLI syntax has changed. Don't mount the device you're trying to recover from, and instead useextundelete --restore-file <path> /dev/<device-file>
.– Ryan LueCommented Nov 9, 2018 at 3:21 -
use "rm-trash" utility which handles puts them to trash for later retrieval and supports all options of "rm" command. Commented Nov 20, 2018 at 14:20
-
Don't use "rm" if you wish to restore the files in future .You can use "rm-trash" utility from apt-get : github.com/nateshmbhat/rm-trash Commented Nov 20, 2018 at 14:30
-
could you explain where the number 22 on ` cp /proc/5383/fd/22 /path/to/restored/file` come from? I am stuck on that part, it gives me 5 different number Commented Aug 12, 2019 at 14:50
-
@AdiPrasetyo: As the answer states the fourth column in the
lsof
output is the number of the file descriptor the process has opened to the file. A process may have multiple open file descriptors to the same file. Commented Aug 13, 2019 at 14:46
Yes, I am able to recover my files. I haven't checked yet whether all are recovered or not but yes a few I have checked are recovered. As there are many many files which are recovered via that tool/command I need to grep some text pattern in those files and see which are mine. The files are recovered with different names (may be generated by system). I got the solution from a different forum and the command is photorec
sudo photorec
This will open a text based window. I followed the instructions and yes it's superb.
-
photorec is a bit more of a brute-force approach. It's worth starting with unmounting and turning to lsof and/or extundelete before turning to photorec. Running photorec on a large capacity drive can take many hours. Commented May 24, 2019 at 21:39
ext3
orext4
, you might have some luck recovering files usingextundelete
.