在Linux下工作的很多人都有过这样的尴尬经历，辛辛苦苦写了很久的代码或者文档，一个不小心就rm掉了，命令行删除一般不会进入回收站，这时候是不是想死的心都有了。
先说说活生生的悲剧是怎么发生的。
先是认认真真写了一个下午脚本setup.sh，在coreV1.1中有一个旧版本但是同名的setup.sh，于是就想删了旧版本的，输入命令：rm / coreV1.1/setup.sh ，结果多输入一个空格。于是悲剧就发生了。旧版本的没删除，当前目录下写了一个下午的setup.sh被彻底删除了！
不过也不要太着急，因为不管是Windows还是Linux，文件的删除只是系统回收了该文件的软件资源，但是在物理上文件的内容仍然保留在存储介质之上，直到下一次被覆盖，格式化了也可以被找回来，除非低格（直接擦除磁盘）了那就真没办法了，但是一般日志式的系统更容易恢复，我的Fedora是Ext4的系统，很容易恢复。
下面就是找回这个setup.sh的过程。
1.安装extundelete
先yum search extundelete 查找这个软件包；
再yum insta extundelete.i686安装。
2. 找到被rm的文件
(0)查看文件系统类型和分区
文件系统类型为ext4，extundelete支持的类型为ext3/ext4 ，
用户文件系统在/dev/mapper/fedora-root根文件系统中，被rm的文件也在这里。
(1) 执行：extundelete --inode 2 /dev/mapper/fedora-root
--inode 2为查找当前目录下的文件和被rm掉的文件。先从根目录查起。
要恢复的setup.sh就在home目录下。
(3) 执行：extundelete --inode 393217 /dev/mapper/fedora-root
home的节点号为393217，--inode 393217就是查看home目录下的文件及被删除的文件。
依次下去，知道找到setup.sh的节点号。
(4) 执行：extundelete --restore-inode 542480 /dev/mapper/fedora-root
setup.sh的节点号为542480，--restore-inode 542480就是恢复这个节点文件。
(5)查看恢复结果
在原来setup.sh的目录下产生了一个RECOVERED_FILES目录，恢复的文件就在这个目录中。
file. 542480就是要恢复的setup.sh。
下面是找回setup.sh全部过程的截图：
如果觉得麻烦，为了以后方便，也可以将以上步骤封装成一个脚本，这样下一次就可以直接执行脚本就行了，我就不封了。