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.
This cmd copies 'all' deleted files on that partition into a RECOVERED_FILES dir inside home dir. This will fill up all the free space i have.

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.
Gave message:

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 :

@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.

Apart from manual fiddling with 'debugfs' I'm not aware of any tool that would cause that. (That doesn't mean there aren't any, just that I only know to use common recovery and forensic tools, and yes, I have helped LQ members recover files successfully more than once.) As the others hinted at it would not be a best practice either.


No, that's just wishful thinking. You may have read the "everything is a file" phrase. Simply put this means each single file is represented by a single inode. It tells the file system where to find the (small) file, where to find the first n blocks (larger file, direct blocks) plus where to find the blocks that point to other blocks (indirect secondary and tertiary block addrs). Given aspects like default file system block size, the size of files and the "cost" attached to disk write ops and how the kernel deals with writes it is no wonder block allocation isn't contiguous and given how a file system like Ext deals with allocation there's generally speaking no need for it either. That's files. Directories are files too in the sense that its inode serves as a kind of "index", holding information about the items it contains. This means that once a directory gets deleted the "index", the link between directory inode and file inode, is gone and recreating the directory inode does not automagically mean re-populating its "index".

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.


What does this mean? That the file system to recover from is an encrypted one and you tried to recover to the same file system?

1 members found this post helpful.

@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.

No, it means i did not read the docs carefully. It needs the path relative to the partition, i gave path wrt root.

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!