Undo rm -rf dir
I accidentally executed "rm -rf" on the wrong directory. After going through various posts on several websites, i have tried photorec, testdisk, extundelete. Only following cmd works.
Code:
sudo extundelete --restore-all /dev/mapper/udisks-xxxxx Is there any way to undelete 'only the directory' in its original location. As directory is technical just a file, wont that in turn recover the files under it? I tried the directory recovery feature of extundelete, but it wont work. Code:
sudo extundelete --restore-directory /media/encryptedPartitionA/mydir/ /dev/mapper/udisks-xxxxx Code:
Failed to restore file /media/encryptedPartitionA/mydir/ |
Restoring directories which have been "rm -rf" is generally Black Magic in Linux - there's a thread on it at least once a month here at LQ, and I've never successfully recovered one. The "solution" is to make regular backups, and not to be trigger-happy with your rm's (zsh at least has a feature where it asks you to confirm that you want to delete the contents of a directory, in case you made a typo). Some people also change their 'rm' command for a command which just moves the file(s) to a trash folder, like deleting files using a window manager.
In terms of trying to fix the problem as it is, do you have any external hard drives (or similar) which you could mount to give you extra room (extundelete makes the 'RECOVERED_FILES' directory in the current directory you're in, which doesn't need to be your home directory)? Or moving some of the files on your hard drive to another computer/hard drive, recovering, deleting the ones you don't need, and restoring the files you moved? |
stop using the "f" option !!!
use "-i" or " -I" and stop using "force" see : Code:
rm --help |
@Snark1994
making more space or using external hdd, is pretty much straight forward, if i opt to use the restore-all way. Was seeking help to avoid that. --- I have been able to get the inode number of the directory that was deleted. Is it possible to grep or dd the 'directory file'? And will getting back 'directory file' in its location lead to reverting back to previous state, i.e, all contents intact? |
Unless you stopped using that partition immediately, its possible the system would have started to re-use that space.
You may be out of luck... |
@chrism01
There is no problem in bulk data retrieval and it is obvious thing that the partition should be kept untouched, until recovery is complete. @all Anyone here ever used grep or dd to retrieve back a directory using inode? I have seen examples of retrieving files with inode information, but not sure about retrieving directory & its consequence. |
Quote:
Quote:
Tools like Photorec, Scalpel and Foremost try to bypass problems by looking for files directly as file types often have a specific header (see 'man magic') and footer. But since block allocation isn't contiguous this may incorporate for example part of a header-less file B between header A and footer C. On top of that, by allowing time to pass, not freezing the file system the instant a deletion happened, the system will continue to re-allocate freed up blocks. And every action be it involuntarily like journal syncing, daemons and subsystems running in the background, or voluntarily like any command you execute in the shell, can trigger a write op. The most encountered mistakes I've seen are installing software, rebooting, running fsck on corrupted file systems, not remounting disks in read-only mode (also see "-o ro,norecovery,noload") and not making a copy of the disk or partition before messing with it. Testdisk allows you to try and "walk" the file system by attaching it to the disk or partition (like for example 'testdisk /debug /log /dev/sda1' for the latter), Proceed > None > Advanced > Undelete. There you should see directories and files in red if unlinked. If it's a very recent deletion you may encounter deleted files listed in the parent directory of the deleted directory where you can select them and copy them to a different partition or disk. Else you can at least use Testdisk as a convenient tool to do recon with and at least verify you can still see items or not. *Talking about convenience: as you can guess from the above file recovery isn't the type of situation where what you would "like" is a valid reason or has any priority but what's possible or not. Quote:
|
@unSpawn
I had used debugfs earlier to get logdumps of the inode, for using with grep for retrieving the directory file. I wrongly assumed that the index to the underlying files was part of the 'directory file' and was hoping that restoring the 'directory file' will fix things. Quote:
After giving the relative path, the directory & its contents were recovered. It pretty good, as i didnt had to use the --restore-all option, which recovers deleted stuff from the entire partition. Thanks for the responses! |
All times are GMT -5. The time now is 11:52 PM. |