We will keep this quick.
I used the rm command and deleted everything. I want it back.
please, help me...
please help
Moderator: General Moderators
From http://www.linux.org/docs/ldp/howto/Ext ... .html#toc4, I would take that hard drive and mount it in a different PC so nothing is written to it. Disk activity will destroy the deleted files.
8. Finding the deleted inodes
The next step is to ask the file system which inodes have recently been freed. This is a task you can accomplish with debugfs. Start debugfs with the name of the device on which the file system is stored:
# debugfs /dev/hda5
If you want to modify the inodes directly, add a -w option to enable writing to the file system:
# debugfs -w /dev/hda5
The debugfs command to find the deleted inodes is lsdel. So, type the command at the prompt:
debugfs: lsdel
After much wailing and grinding of disk mechanisms, a long list is piped into your favourite pager (the value of $PAGER). Now you'll want to save a copy of this somewhere else. If you have less, you can type -o followed by the name of an output file. Otherwise, you'll have to arrange to send the output elsewhere. Try this:
debugfs: quit
# echo lsdel | debugfs /dev/hda5 > lsdel.out
Now, based only on the deletion time, the size, the type, and the numerical permissions and owner, you must work out which of these deleted inodes are the ones you want. With luck, you'll be able to spot them because they're the big bunch you deleted about five minutes ago. Otherwise, trawl through that list carefully.
I suggest that if possible, you print out the list of the inodes you want to recover. It will make life a lot easier.
For each inode you want to recover, you must set the usage count to one, and set the deletion time to zero. This is done with the mi (modify inode) command in debugfs. Some sample output, modifying inode 148003 from above:
debugfs: mi <148003>
Mode [0100644]
User ID [503]
Group ID [100]
Size [6065]
Creation time [833201524]
Modification time [832708049]
Access time [826012887]
Deletion time [833201524] 0
Link count [0] 1
Block count [12]
File flags [0x0]
Reserved1 [0]
File acl [0]
Directory acl [0]
Fragment address [0]
Fragment number [0]
Fragment size [0]
Direct Block #0 [594810]
Direct Block #1 [594811]
Direct Block #2 [594814]
Direct Block #3 [594815]
Direct Block #4 [594816]
Direct Block #5 [594817]
Direct Block #6 [0]
Direct Block #7 [0]
Direct Block #8 [0]
Direct Block #9 [0]
Direct Block #10 [0]
Direct Block #11 [0]
Indirect Block [0]
Double Indirect Block [0]
Triple Indirect Block [0]
That is, I set the deletion time to 0 and the link count to 1 and just pressed return for each of the other fields. Granted, this is a little unwieldy if you have a lot of files to recover, but I think you can cope. If you'd wanted chrome, you'd have used a graphical `operating system' with a pretty `Recycle Bin'.
By the way: the mi output refers to a `Creation time' field in the inode. This is a lie! (Or misleading, anyway.) The fact of the matter is that you cannot tell on a UNIX file system when a file was created. The st_ctime member of a struct stat refers to the `inode change time', that is, the last time when any inode details were changed. Here endeth today's lesson.
Note that more recent versions of debugfs than the one I'm using probably do not include some of the fields in the listing above (specifically, Reserved1 and (some of?) the fragment fields).
Once you've modified the inodes, you can quit debugfs and say:
# e2fsck -f /dev/hda5
The idea is that each of the deleted files has been literally undeleted, but none of them appear in any directory entries. The e2fsck program can detect this, and will add a directory entry for each file in the /lost+found directory of the file system. (So if the partition is normally mounted on /usr, the files will now appear in /usr/lost+found when you next mount it.) All that still remains to be done is to work out the name of each file from its contents, and return it to its correct place in the file system tree.
When you run e2fsck, you will get some informative output, and some questions about what damage to repair. Answer `yes' to everything that refers to `summary information' or to the inodes you've changed. Anything else I leave up to you, although it's usually a good idea to say `yes' to all the questions. When e2fsck finishes, you can remount the file system.
Actually, there's an alternative to having e2fsck leave the files in /lost+found: you can use debugfs to create a link in the file system to the inode. Use the link command in debugfs after you've modified the inode:
debugfs: link <148003> foo.txt
This creates a file called foo.txt in what debugfs thinks is the current directory; foo.txt will be your file. You'll still need to run e2fsck to fix the summary information and block counts and so on.
8. Finding the deleted inodes
The next step is to ask the file system which inodes have recently been freed. This is a task you can accomplish with debugfs. Start debugfs with the name of the device on which the file system is stored:
# debugfs /dev/hda5
If you want to modify the inodes directly, add a -w option to enable writing to the file system:
# debugfs -w /dev/hda5
The debugfs command to find the deleted inodes is lsdel. So, type the command at the prompt:
debugfs: lsdel
After much wailing and grinding of disk mechanisms, a long list is piped into your favourite pager (the value of $PAGER). Now you'll want to save a copy of this somewhere else. If you have less, you can type -o followed by the name of an output file. Otherwise, you'll have to arrange to send the output elsewhere. Try this:
debugfs: quit
# echo lsdel | debugfs /dev/hda5 > lsdel.out
Now, based only on the deletion time, the size, the type, and the numerical permissions and owner, you must work out which of these deleted inodes are the ones you want. With luck, you'll be able to spot them because they're the big bunch you deleted about five minutes ago. Otherwise, trawl through that list carefully.
I suggest that if possible, you print out the list of the inodes you want to recover. It will make life a lot easier.
For each inode you want to recover, you must set the usage count to one, and set the deletion time to zero. This is done with the mi (modify inode) command in debugfs. Some sample output, modifying inode 148003 from above:
debugfs: mi <148003>
Mode [0100644]
User ID [503]
Group ID [100]
Size [6065]
Creation time [833201524]
Modification time [832708049]
Access time [826012887]
Deletion time [833201524] 0
Link count [0] 1
Block count [12]
File flags [0x0]
Reserved1 [0]
File acl [0]
Directory acl [0]
Fragment address [0]
Fragment number [0]
Fragment size [0]
Direct Block #0 [594810]
Direct Block #1 [594811]
Direct Block #2 [594814]
Direct Block #3 [594815]
Direct Block #4 [594816]
Direct Block #5 [594817]
Direct Block #6 [0]
Direct Block #7 [0]
Direct Block #8 [0]
Direct Block #9 [0]
Direct Block #10 [0]
Direct Block #11 [0]
Indirect Block [0]
Double Indirect Block [0]
Triple Indirect Block [0]
That is, I set the deletion time to 0 and the link count to 1 and just pressed return for each of the other fields. Granted, this is a little unwieldy if you have a lot of files to recover, but I think you can cope. If you'd wanted chrome, you'd have used a graphical `operating system' with a pretty `Recycle Bin'.
By the way: the mi output refers to a `Creation time' field in the inode. This is a lie! (Or misleading, anyway.) The fact of the matter is that you cannot tell on a UNIX file system when a file was created. The st_ctime member of a struct stat refers to the `inode change time', that is, the last time when any inode details were changed. Here endeth today's lesson.
Note that more recent versions of debugfs than the one I'm using probably do not include some of the fields in the listing above (specifically, Reserved1 and (some of?) the fragment fields).
Once you've modified the inodes, you can quit debugfs and say:
# e2fsck -f /dev/hda5
The idea is that each of the deleted files has been literally undeleted, but none of them appear in any directory entries. The e2fsck program can detect this, and will add a directory entry for each file in the /lost+found directory of the file system. (So if the partition is normally mounted on /usr, the files will now appear in /usr/lost+found when you next mount it.) All that still remains to be done is to work out the name of each file from its contents, and return it to its correct place in the file system tree.
When you run e2fsck, you will get some informative output, and some questions about what damage to repair. Answer `yes' to everything that refers to `summary information' or to the inodes you've changed. Anything else I leave up to you, although it's usually a good idea to say `yes' to all the questions. When e2fsck finishes, you can remount the file system.
Actually, there's an alternative to having e2fsck leave the files in /lost+found: you can use debugfs to create a link in the file system to the inode. Use the link command in debugfs after you've modified the inode:
debugfs: link <148003> foo.txt
This creates a file called foo.txt in what debugfs thinks is the current directory; foo.txt will be your file. You'll still need to run e2fsck to fix the summary information and block counts and so on.