dev3 linux删除文件,【转】如何恢复 Linux 上删除的文件(3)

怼烎@ 2023-01-20 11:59 150阅读 0赞

符号链接

我们知道，在 ext2

文件系统中，链接可以分为两种：硬链接和符号链接(或称为软链接)。实际上，目录中的每个文件名都对应一个硬链接。硬链接的出现是为了解决使用不同的文件名来引用同一个文件的问题。如果没有硬链接，只能通过给现有文件新建一份拷贝才能通过另外一个名字来引用这个文件，这样做的问题是在文件内容发生变化的情况下，势必会造成引用这些文件的进程所访问到的数据不一致的情况出现。而虽然每个硬链接在文件目录项中都是作为一个单独的项存在的，但是其索引节点号完全相同，这就是说它们引用的是同一个索引节点，因此对应的文件数据也完全相同。下面让我们通过一个例子来验证一下：

清单21.硬链接采用相同的索引节点号

\# ln testfile.10M hardlink.10M

\# ls -li

total 20592

12 -rwxr-xr-x 1 root root 1406 Nov 29 19:19 createfile.sh

1205313 drwxr-xr-x 2 root root 4096 Nov 29 19:29 dir1

14 -rw-r--r-- 2 root root 10485760 Nov 29 19:21 hardlink.10M

11 drwx------ 2 root root 16384 Nov 29 19:19 lost+found

14 -rw-r--r-- 2 root root 10485760 Nov 29 19:21 testfile.10M

13 -rw-r--r-- 1 root root 35840 Nov 29 19:20 testfile.35K

我们可以看到，使用 ln 建立的硬链接 hardlink.10M 的索引节点号也是 14，这与 testfile.10M

的索引节点号完全相同，因此通过这两个名字所访问到的数据是完全一致的。

因此，硬链接的恢复与普通文件的恢复非常类似，唯一的区别在于如果索引节点指向的数据已经恢复出来了，现在就无需再恢复数据了，只需要恢复其父目录中的对应目录项即可，这可以通过

debugfs 的 link 命令实现。

硬件链接的出现虽然可以满足通过不同名字来引用相同文件的需要，但是也存在一些问题，包括：

不能对目录建立硬链接，否则就会引起循环引用的问题，从而导致最终正常路径的无法访问。

不能建立跨文件系统的硬链接，这是由于每个文件系统中的索引节点号都是单独进行编号的，跨文件系统就会导致索引节点号变得非常混乱。而这在现代

Linux/Unix 操作系统上恰恰是无法接受的，因为每个文件系统中都可能会有很多挂载点来挂载不同的文件系统。

为了解决上面的问题，符号链接就应运而生了。符号链接与硬链接的区别在于它要占用一个单独的索引节点来存储相关数据，但却并不存储链接指向的文件的数据，而是存储链接的路径名：如果这个路径名小于60个字符，就其存储在符号链接索引节点的

i\_block 域中；如果超过 60 个字符，就使用一个单独的数据块来存储。下面让我们来看一个例子：

清单22. 符号链接采用不同的索引节点号

\# ln -s testfile.10M softlink.10M

\# ls -li

total 20596

12 -rwxr-xr-x 1 root root 1406 Nov 29 19:19 createfile.sh

1205313 drwxr-xr-x 2 root root 4096 Nov 29 19:29 dir1

14 -rw-r--r-- 2 root root 10485760 Nov 29 19:21 hardlink.10M

11 drwx------ 2 root root 16384 Nov 29 19:19 lost+found

15 lrwxrwxrwx 1 root root 12 Nov 29 19:41 softlink.10M -> testfile.10M

14 -rw-r--r-- 2 root root 10485760 Nov 29 19:21 testfile.10M

13 -rw-r--r-- 1 root root 35840 Nov 29 19:20 testfile.35K

\# echo "stat <15>" | debugfs /dev/sdb6

debugfs 1.39 (29-May-2006)

debugfs: Inode: 15 Type: symlink Mode: 0777 Flags: 0x0 Generation: 2344716327

User: 0 Group: 0 Size: 12

File ACL: 1542 Directory ACL: 0

Links: 1 Blockcount: 8

Fragment: Address: 0 Number: 0 Size: 0

ctime: 0x474ea56f -- Thu Nov 29 19:41:35 2007

atime: 0x474ea571 -- Thu Nov 29 19:41:37 2007

mtime: 0x474ea56f -- Thu Nov 29 19:41:35 2007

Fast\_link\_dest: testfile.10M

ln 命令的 –s 参数就用来指定创建一个符号链接。从结果中可以看出，新创建的符号链接使用的索引节点号是 15，索引节点中的

i\_block 中存储的值就是这个符号链接所指向的目标：testfile.10M(Fast\_link\_dest 的值)。

现在再来看一个指向长路径的符号链接的例子：

清单23. 长名符号链接

\# touch abcdwfghijklmnopqrstuvwxyz0123456789abcdwfghijklmnopqrstuvwxyz0123456789.sh

\# ln -s abcdwfghijklmnopqrstuvwxyz0123456789abcdwfghijklmnopqrstuvwxyz0123456789.sh \\

longsoftlink.sh

\# ls -li

total 20608

16 -rw-r--r-- 1 root root 0 Nov 29 19:52 \\

abcdwfghijklmnopqrstuvwxyz0123456789abcdwfghijklmnopqrstuvwxyz0123456789.sh

12 -rwxr-xr-x 1 root root 1406 Nov 29 19:19 createfile.sh

1205313 drwxr-xr-x 2 root root 4096 Nov 29 19:29 dir1

14 -rw-r--r-- 2 root root 10485760 Nov 29 19:21 hardlink.10M

17 lrwxrwxrwx 1 root root 75 Nov 29 19:53 longsoftlink.sh -> \\

abcdwfghijklmnopqrstuvwxyz0123456789abcdwfghijklmnopqrstuvwxyz0123456789.sh

11 drwx------ 2 root root 16384 Nov 29 19:19 lost+found

15 lrwxrwxrwx 1 root root 12 Nov 29 19:41 softlink.10M -> testfile.10M

14 -rw-r--r-- 2 root root 10485760 Nov 29 19:21 testfile.10M

13 -rw-r--r-- 1 root root 35840 Nov 29 19:20 testfile.35K

\# echo "stat <17>" | debugfs /dev/sdb6

debugfs 1.39 (29-May-2006)

debugfs: Inode: 17 Type: symlink Mode: 0777 Flags: 0x0 Generation: 744523175

User: 0 Group: 0 Size: 75

File ACL: 1542 Directory ACL: 0

Links: 1 Blockcount: 16

Fragment: Address: 0 Number: 0 Size: 0

ctime: 0x474ea824 -- Thu Nov 29 19:53:08 2007

atime: 0x474ea826 -- Thu Nov 29 19:53:10 2007

mtime: 0x474ea824 -- Thu Nov 29 19:53:08 2007

BLOCKS:

(0):6144

TOTAL: 1

此处我们创建了一个名字长度为 75 个字符的文件，并建立一个符号链接(其索引节点号是

17)指向这个文件。由于链接指向的位置路径名超过了 60

个字符，因此还需要使用一个数据块(6144)来存储这个路径名。手工恢复方法如下：

清单24. 恢复长名符号链接

\# dd if=/dev/sdb6 of=longsoftlink.6144 bs=4096 count=1 skip=6144

\# xxd longsoftlink.6144 | more

0000000: 6162 6364 7766 6768 696a 6b6c 6d6e 6f70 abcdwfghijklmnop

0000010: 7172 7374 7576 7778 797a 3031 3233 3435 qrstuvwxyz012345

0000020: 3637 3839 6162 6364 7766 6768 696a 6b6c 6789abcdwfghijkl

0000030: 6d6e 6f70 7172 7374 7576 7778 797a 3031 mnopqrstuvwxyz01

0000040: 3233 3435 3637 3839 2e73 6800 0000 0000 23456789.sh.....

0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................

这样符号链接的数据就可以完整地恢复出来了。

需要注意的是，为了保证整个文件系统的完整性，在恢复硬链接时，还需要修改链接指向的索引节点的引用计数值，这可以使用 e2fsck

帮助完成，详细步骤请参看上一节目录的恢复。

![a4c26d1e5885305701be709a3d33442f.png][]

小结

本文介绍了 ext2 文件系统中比较特殊的一些文件的存储和恢复机制，包括文件洞、目录和链接，并介绍了如何结合使用 debugfs

和 e2fsck 等工具完整恢复 ext2 文件系统的方法。在本系列的后续文章中，我们将介绍几个可以自动恢复 ext2

文件系统中已删除文件的工具，以及对 ext2 文件系统的后继者 ext3 和 ext4 文件系统的一些考虑。

恢复系统中删除的文件是一个非常繁琐的过程，而 e2undel

这个工具可以用来方便地恢复文件系统中已删除的文件。本文将首先讨论 e2undel

的工作原理和用法，并对之进行一些改进。然后讨论了文件系统故障、文件系统重建、磁盘物理损坏等情况下应该如何恢复数据。

在本系列文章的前两部分中，我们介绍了 ext2 文件系统中各种文件在磁盘上的存储结构，以及如何利用 debugfs

工具的辅助，手工恢复这些文件的详细过程。

通过这两部分的学习，我们可以看出恢复系统中删除的文件是一个非常繁琐的过程，需要非常仔细地考虑各种情况，并且要保持足够的细心，才可能把数据准确无误地恢复出来。稍有差错，就会造成数据丢失的情况。聪明的读者肯定会想，如果有一些好工具来自动或辅助完成数据的恢复过程，那简直就太好了。

幸运的是，已经有人开发了这样一些工具，来简化用户的数据恢复工作，e2undel 就是其中功能最为强大的一个。

自动恢复工具 e2undel

回想一下，在 ext2 文件系统中删除一个文件时，该文件本身的数据并没有被真正删除，实际执行的操作如下：

在块位图中将该文件所占用的数据块标识为可用状态。

在索引节点位图中将该文件所占用的索引节点标识为可用状态。

将该文件索引节点中的硬链接数目设置为 0。

将该文件索引节点中的删除时间设置为当前时间。

将父目录项中该文件对应项中的索引节点号设置为 0，并扩展前一项，使其包含该项所占用的空间。

而索引节点中的一些关键信息(或称为元数据，包括文件属主、访问权限、文件大小、该文件所占用的数据块等)都并没有发生任何变化。因此只要知道了索引节点号，就完全可以用本系列文章介绍的技术将文件完整地从磁盘上恢复出来了，这正是

e2undel 之类的工具赖以生存的基础。

然而，由于所删除的文件在目录项中对应的项中的索引节点号被清空了，因此我们就无法从索引节点中获得文件名的信息了。不过，由于文件大小、属主和删除时间信息依然能反映文件的原始信息，因此我们可以通过这些信息来帮助判断所删除的文件是哪个。

e2undel 是由Oliver Diedrich 开发的一个用来恢复 ext2

文件系统中已删除文件的工具，它会遍历所检测的文件系统的索引节点表，从中找出所有被标记为删除的索引节点，并按照属主和删除时间列出这些文件。另外，e2undel

还提供了文件大小信息，并试图按照 file 命令的方式来确定文件类型。如果您使用 rm –rf \*

之类的命令一次删除了很多文件，这种信息就可以用来非常方便地帮助确定希望恢复的是哪些文件。在选择要恢复的文件之后，e2undel

会从磁盘上读取该文件占用的数据块(这些数据块的信息全部保存在索引节点中)，并将其写入到一个新文件中。下面我们来看一下 e2undel

这个工具的详细用法。

首先请从 e2undel

的主页(http://e2undel.sourceforge.net/)上下载最新的源码包(截止到撰写本文为止，最新的版本是

0.82)，并将其保存到本地文件系统中。不过这个源码包在最新的 Fedora Core 8 上编译时可能会有些问题，这是由于 ext2

文件系统内部实现中一些数据结构的变化引起来的，读者可以下载本文“下载”部分给出的补丁来修正这个问题(请下载这个补丁文件

e2undel-0.82.patch，并将其保存到与源码包相同的目录中)。要想编译 e2undel，系统中还必须安装

e2fsprogs 和 e2fsprogs-devel 这两个包，其中有编译 e2undel 所需要的一些头文件。Fedora

Core 8 中自带的这两个包的版本号是 1.39-7：

清单1. 确认系统中已经安装了 e2fsprogs 和 e2fsprogs-devel

\# rpm -qa | grep e2fsprogs

e2fsprogs-libs-1.39-7

e2fsprogs-1.39-7

e2fsprogs-devel-1.39-7

现在就可以开始编译 e2undel 了：

清单2. 编译 e2undel

\# tar -zxf e2undel-0.82.tgz

\# patch -p0 < e2undel-0.82.patch

patching file e2undel-0.82/Makefile

patching file e2undel-0.82/e2undel.h

patching file e2undel-0.82.orig/libundel.c

\# cd e2undel-0.82

\# make all

编译之后会生成一个名为 e2undel 的可执行文件，其用法如下：

清单3. e2undel 的用法

\# ./e2undel

./e2undel 0.82

usage: ./e2undel -d device -s path \[-a\] \[-t\]

usage: ./e2undel -l

'-d': file system where to look for deleted files

'-s': directory where to save undeleted files

'-a': work on all files, not only on those listed in undel log file

'-t': try to determine type of deleted files w/o names, works only with '-a'

'-l': just give a list of valid files in undel log file

e2undel 实际上并没有像前面介绍的使用 e2fsck

那样的方法一样真正将已经删除的文件恢复到原来的文件系统中，因为它并不会修改磁盘上 ext2

使用的内部数据结构(例如索引节点、块位图和索引节点位图)。相反，它仅仅是将所删除文件的数据恢复出来并将这些数据保存到一个新文件中。因此，-s

参数指定是保存恢复出来的文件的目录，最好是在另外一个文件系统上，否则可能会覆盖磁盘上的原有数据。如果指定了 -t 参数，e2undel

会试图读取文件的前 1KB 数据，并试图从中确定该文件的类型，其原理与系统中的 file

命令非常类似，这些信息可以帮助判断正在恢复的是什么文件。

下面让我们来看一个使用 e2undel 恢复文件系统的实例。

清单4. 使用 e2undel 恢复文件的实例

\# ./e2undel -a -t -d /dev/sda2 -s /tmp/recover/

./e2undel 0.82

Trying to recover files on /dev/sda2, saving them on /tmp/recover/

/dev/sda2 opened for read-only access

/dev/sda2 was not cleanly unmounted.

Do you want wo continue (y/n)? y

489600 inodes (489583 free)

977956 blocks of 4096 bytes (941677 free)

last mounted on Fri Dec 28 16:21:50 2007

reading log file: opening log file: No such file or directory

no entries for /dev/sda2 in log file

searching for deleted inodes on /dev/sda2:

|==================================================|

489600 inodes scanned, 26 deleted files found

user name | 1 <12 h | 2 <48 h | 3 <7 d | 4 <30 d | 5 <1 y | 6 older

\-------------+---------+---------+---------+---------+---------+--------

root | 0 | 0 | 0 | 2 | 0 | 0

phost | 24 | 0 | 0 | 0 | 0 | 0

Select user name from table or press enter to exit: root

Select time interval (1 to 6) or press enter to exit: 4

inode size deleted at name

\-----------------------------------------------------------

13 35840 Dec 19 17:43 2007 \* ASCII text

14 10485760 Dec 19 17:43 2007 \* ASCII text

Select an inode listed above or press enter to go back: 13

35840 bytes written to /tmp/recover//inode-13-ASCII\_text

Select an inode listed above or press enter to go back:

user name | 1 <12 h | 2 <48 h | 3 <7 d | 4 <30 d | 5 <1 y | 6 older

\-------------+---------+---------+---------+---------+---------+--------

root | 0 | 0 | 0 | 2 | 0 | 0

phost | 24 | 0 | 0 | 0 | 0 | 0

Select user name from table or press enter to exit:

e2undel 是一个交互式的命令，命令执行过程中需要输入的内容已经使用黑体表示出来了。从输出结果中可以看出，e2undel

一共在这个文件系统中找到了 26 个文件，其中 root 用户删除的有两个。这些文件按照删除时间的先后顺序被划分到几类中。索引节点号

13 对应的是一个 ASCII 正文的文本文件，最终被恢复到 /tmp/recover//inode-13-ASCII\_text

文件中。查看一下这个文件就会发现，正是我们在本系列前两部分中删除的那个 35KB 的测试文件。

利用 libundel 库完美恢复文件

尽管 e2undel

可以非常方便地简化恢复文件的过程，但是美中不足的是，其恢复出来的文件的文件名却丢失了，其原因是文件名是保存在父目录的目录项中的，而不是保存在索引节点中的。本系列文章第

部分中给出了一种通过遍历父目录的目录项来查找已删除文件的文件名的方法，但是由于索引节点会被重用，因此通过这种方式恢复出来的文件名也许并不总是正确的。另外，如果目录结构的非常复杂，就很难确定某个文件的父目录究竟是哪个，因此查找正确文件名的难度就会变得很大。如果能在删除文件时记录下索引节点号和文件名之间的对应关系，这个问题就能完美地解决了。

这个问题在 e2undel 中得到了完美的解决。实际上，所有删除命令，例如 rm、unlink 都是通过一些底层的系统调用(例如

unlink(2)、rmdir(2))来实现的。基于这一点，e2undel 又利用了Linux

系统中动态链接库加载时提供的一种便利：如果设置了环境变量 LD\_PRELOAD，那么在加载动态链接库时，会优先从

$LD\_PRELOAD 指向的动态链接库中查找符号表，然后才会在系统使用 ldconfig

配置的动态链接库中继续查找符号表。因此，我们可以在自己编写的库函数中实现一部分系统调用，并将这个库优先于系统库加载，这样就能欺骗系统使用我们自己定义的系统调用来执行原有的操作。具体到

e2undel 上来说，就是要在调用这些系统调用删除文件时，记录下文件名和索引节点号之间的对应关系。

在编译 e2undel 源代码之后，还会生成一个库文件

libundel.so.1.0，其中包含了删除文件时所使用的一些系统调用的钩子函数。e2undel官方主页上下载的源码包中仅仅包括了对

unlink(2) 和 remove(3) 这两个系统调用的钩子函数，但是从 2.6.16

版本的内核开始，引入了一系列新的系统调用，包括 faccessat(2), fchmodat(2), fchownat(2),

fstatat(2), futimesat(2), linkat(2), mkdirat(2), mknodat(2),

openat(2), readlinkat(2), renameat(2), symlinkat(2), unlinkat(2),

mkfifoat(3) 等，尽管这些系统调用目前还没有成为POSIX标准的一部分，但是相信这个过程不会很久了。目前诸如 Fecora

Core 8 之类的系统中自带的 rm 命令(属于

coreutils)包已经使用这些新的系统调用进行了改写，另外本文下载部分中的补丁文件中已经提供了对 rmdir 和 unlinkat

的钩子函数。部分源代码如下所示：

清单5. libundel.c 代码片断

void \_init()

f = fopen("/var/e2undel/e2undel", "a");

if (!f)

fprintf(stderr, "libundel: can't open log file, undeletion disabled\\n");

......

int rmdir(const char \*pathname)

int err;

struct stat buf;

char pwd\[PATH\_MAX\];

int (\*rmdirp)(char \*) = dlsym(RTLD\_NEXT, "rmdir");

if (NULL != pathname)

if (\_\_lxstat(3, pathname, &buf)) buf.st\_ino = 0;

if (!realpath(pathname, pwd)) pwd\[0\] = '\\0';

err = (\*rmdirp)((char \*) pathname);

if (err) return err;

if (f)

if (!S\_ISLNK(buf.st\_mode))

fprintf(f, "%ld,%ld::%ld::%s\\n",

(long) (buf.st\_dev & 0xff00) / 256,

(long) buf.st\_dev & 0xff,

(long) buf.st\_ino, pwd\[0\] ? pwd : pathname);

fflush(f);

return err;

......

void \_fini()

if (f) fclose(f);

\_init 和 \_fini 这两个函数分别在打开和关闭动态链接库时执行，分别用来打开和关闭日志文件。如果某个命令(例如

rm)执行了 rmdir 系统调用，就会被这个库接管。rmdir 的处理比较简单，它先搜索到真正的 rmdir

系统调用的符号表，然后使用同样的参数来执行这个系统调用，如果成功，就将有关索引节点和文件名之类的信息记录到日志中(默认是

/var/e2undel/ e2undel)。

这个库的使用非常简单，请执行下面的命令：

清单6. libundel 的设置

\# cp libundel.so.1.0 /usr/local/lib

\# cd /usr/local/lib

\# ln -s libundel.so.1.0 libundel.so.1

\# ln –s libundel.so.1.0 libundel.so

\# ldconfig

\# mkdir /var/e2undel

\# chmod 711 /var/e2undel

\# touch /var/e2undel/e2undel

\# chmod 622 /var/e2undel/e2undel

上面的设置仅仅允许 root 用户可以恢复文件，如果希望让普通用户也能恢复文件，就需要修改对应文件的权限设置。

现在尝试以另外一个用户的身份来删除些文件：

清单7. 设置libundel之后删除文件

$ export LD\_PRELOAD=/usr/local/lib/libundel.so

$ rm -rf e2undel-0.82

要想记录所有用户的删除文件的操作，可以将 export

LD\_PRELOAD=/usr/local/lib/libundel.so 这行内容加入到 /etc/profile 文件中。

现在使用 e2undel 来恢复已删除的文件就变得简单多了，因为已经可以通过文件名来恢复文件了：

清单8. e2undel 利用 libundel 日志恢复删除文件

\# ./e2undel -a -t -d /dev/sda2 -s /tmp/recover/

./e2undel 0.82

Trying to recover files on /dev/sda2, saving them on /tmp/recover/

/dev/sda2 opened for read-only access

/dev/sda2 was not cleanly unmounted.

Do you want wo continue (y/n)? y

489600 inodes (489531 free)

977956 blocks of 4096 bytes (941559 free)

last mounted on Fri Dec 28 20:45:05 2007

reading log file:

found 24 entries for /dev/sda2 in log file

searching for deleted inodes on /dev/sda2:

|==================================================|

489600 inodes scanned, 26 deleted files found

checking names from log file for deleted files: 24 deleted files with names

user name | 1 <12 h | 2 <48 h | 3 <7 d | 4 <30 d | 5 <1 y | 6 older

\-------------+---------+---------+---------+---------+---------+--------

root | 0 | 0 | 0 | 2 | 0 | 0

phost | 24 | 0 | 0 | 0 | 0 | 0

Select user name from table or press enter to exit: phost

Select time interval (1 to 6) or press enter to exit: 1

inode size deleted at name

\-----------------------------------------------------------

310083 0 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82

310113 2792 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/BUGS

310115 3268 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/HISTORY

310116 1349 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/INSTALL

310117 1841 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/INSTALL.de

310118 2175 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/Makefile

310119 12247 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/README

310120 9545 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/README.de

310121 13690 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/apprentice.c

310122 19665 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/ascmagic.c

310123 221 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/common.h

310124 1036 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/compactlog.c

310125 30109 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/e2undel.c

310127 2447 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/e2undel.h

310128 1077 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/file.c

310129 2080 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/file.h

310130 4484 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/find\_del.c

310131 2141 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/is\_tar.c

310132 2373 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/libundel.c

310133 7655 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/log.c

310134 39600 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/magic.h

310135 4591 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/names.h

310136 13117 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/softmagic.c

310137 5183 Dec 29 17:23 2007 /tmp/test/undel/e2undel-0.82/tar.h

如果对所有用户都打开这个功能，由于日志文件是单向增长的，随着时间的推移，可能会变得很大，不过 e2undel 中还提供了一个

compactlog 工具来删除日志文件中的重复项。

在学习本系列文章介绍的技术之后，利用 e2undel

之类的工具，并使用本系列文章第一部分中提供的补丁，恢复删除文件就变得非常简单了。但是在日常使用过程中，大家可能还会碰到一些意外的情况，比如文件系统发生问题，从而无法正常挂载；使用

mke2fs

之类的工具重做了文件系统；甚至磁盘上出现坏道。此时应该如何恢复系统中的文件呢，下面让我们来逐一看一下如何解决这些问题。

![a4c26d1e5885305701be709a3d33442f.png][]

[a4c26d1e5885305701be709a3d33442f.png]: /images/20221021/40a9ff96b824473a85db4972c751ec8f.png

dev3 linux删除文件,【转】如何恢复 Linux 上删除的文件(3)

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 Linux删除3天前的归档日志文件

相关 dev3 linux删除文件,【转】如何恢复 Linux 上删除的文件(3)

相关 linux删除del后缀文件,linux删除命令_linux下如何删除一个文件？

相关 oracle物理文件删除如何恢复,物理删除oracle数据文件的恢复

相关 Linux Ext3文件被删除后的恢复方法介绍

相关 Linux文件误删除恢复操作

相关 linux下rm删除文件的恢复

相关 linux删除文件

相关如何在Linux上恢复误删除的文件或目录

相关 Linux lsof命令以及恢复删除的文件