---
name: "e2undel"
section: "8"
platform: "linux"
package: "e2undel"
version: "0.82-1.1"
release: "Debian 7 (Wheezy)"
platforms: ["linux"]
url: "https://new.carta.tech/e2undel"
---

# e2undel(8)

Undelete files on ext2 file systems interactively

## NAME

e2undel — Undelete files on ext2 file systems interactively

## SYNOPSIS

**e2undel** -d device -s path \[-a\]  \[-t\]

## COPYRIGHT

**e2undel** (C) Oliver Diedrich e2undel@sourceforge.net; file type functionality from  the [**file**(1)](/file/1.md) program, (C) (1987) Ian F. Darwin

## DESCRIPTION

Read this *entire* section before continuing! This  section contains the usage description, for a more technical overview  see the *NOTES section*. Please have a look  at the *SETUP section* if you want to use the  \`\`*recover deleted files by name*'' feature  or if you want to give users other than root the ability to undelete.

**e2undel** searches all inodes marked as deleted  on a file system and lists them assorted by owner and time of deletion.  Additionally, it gives you the file size and tries to determine the file  type in the way [**file**(1)](/file/1.md) does. If you did not  just delete a whole bunch of files with a 'rm -r \*', this information should  be helpful to find out which of the deleted files you would like to recover.

**e2undel** does not actually undelete a file  (i.e., does not manipulate ext2 internal structures like inode, block  bitmap, and inode bitmap). Instead it recovers the data of a deleted  file and saves it in a new file.

The following general rules should be kept in mind when undeleting files:

- •

  The device from which you want to recover deleted files should not be mounted  in order to minimize the risk that other processes overwrite data of  deleted files.

- •

  If the device is mounted, the directory where you want to save the files should  not reside on the same device. If it does, there is a chance the recently  restored files overwrite deleted data.

- •

  The sooner as you try to recover a deleted file the higher are chances that you  will succeed.

## OPTIONS

**e2undel** accepts the following parameters:

- **-d device**

  the file system where to look for deleted files  (e.g.  **/dev/hdb1**  for the 1st  partition on the 2nd IDE drive)

- **-s path**

  the directory where recovered files are saved.

- **-a**

  work on all files, not only on those listed in undel log file  (you need this if you don't use the undel library)

- **-t**

  try to determine type of deleted files without names, works   only with **-a**.

- **-l**

  list all non-redundant entries in the libundel log file, sorted by file  systems. Redundant entries can exist after using the undel library for some  time if several files are stored and deleted on the same inode. You can use  the tool **compactlog**(8) to remove these redundant  entries if the log file grows too heavy.

Deleted files are displayed in a table user name by deletion interval.  The deletion intervals are less than 12 hours/48 hours/one week/one   month/one year, with for example \`\`*one month*'' meaning  \`\`*older than one week,*  *but less than one month ago*''.  After selecting a user and a time interval, a list of matching files  is displayed with inode number, owner, deletion date, and name.  If you used the **-a** and the **-t** options, deleted files not found in the  log file are displayed with their file type instead of name, starting with  a '\*' (to have a visual difference between file names and file types).  Files printed in red are partially overwritten.  Enter the inode of a file to recover. Its data is stored in the directory  given  with the **-s** option. If the name of the file is known, it will by used  for the  name of the recovered file, replacing all "/" in its path by "\_".  If the name is not known, the name will be built from the inode  number and -- if available --  its file type in the way \`\`*inode-xxx-file\_type*''.

## EXAMPLE

An example:

**e2undel -d /dev/hdb2 -s /tmp**

tries to restore deleted files on **/dev/hdb2** and saves  them in **/tmp**. Deleted files with no name entry in the  log file are ignored.

## IMPORTANT

As soon as you realize you lost data, unmount the partition as soon as  possible.

## BUGS

- •

  missing pager functionality when displaying the list of deleted files,  you need a terminal with a scrollback buffer

- •

  no direct way to recover a file by name

- •

  some minor stuff, see BUGS (on Debian/GNU Linux system this file can  be found in **/usr/share/doc/e2undel**).

## SETUP

Included in the **e2undel** package  is the undel library. This package is currently  *not* build for Debian/GNU Linux.  This library, loaded by the $LD\_PRELOAD mechanism,  hooks into the system calls [**unlink**(2)](/unlink/2.md) and   [**remove**(3)](/remove/3.md).   libundel logs the device  (like **/dev/hdb7** etc.), the inode number,  and the name of each file  that is deleted by these system calls in a log file   (**/var/e2undel/e2undel** by default).  With this information, it is possible to recover deleted files by name.  Of course, **e2undel** also works without the undel  library (as outlined above), but you lose the functionality to recover  deleted files by name if you don't use libundel  -- maybe the best part of this tool.

First, if you want to use the \`\`*recover deleted files by name*'' feature, you need  read access to libundel's log file **/var/e2undel/e2undel** (and, of course, the undelete library must be installed). When following the  installation instructions, read access to the libundel log is granted  only for root. If *ordinary* users  are allowed to use **e2undel**, you must change the  rights of the libundel log file accordingly (but read the   *SECURITY* section first !). Of course, you can only recover files by name that  were deleted after installing the undelete library. Other deleted files,  however, are displayed when using the **-a** option.

Second, you need read access to the raw file system device  (like **/dev/hdb3** or **/dev/sda9**).  Most distributions grant read access to file system devices only to root  and to a special group (called "disk" on **Red Hat** systems, for example).  If other users are allowed to use **e2undel**,  you either have to change the access rights of the device or must add  these users to the raw disk access group but first see the   *SECURITY* section below.

## SECURITY

**/var/log/e2undel**:   Each process on the system requires write access to this file. You might  consider this before using the undel library on a real multi user system.

If you give all users read access to the log (needed to use   **e2undel**), every user can access each deleted file.  Access rights and owner of deleted files are ignored. This can be considered  a problem in a multi user environment. This also holds true if every user  has read access to the file system device files. You can't have the one  without the other: If a user can recover deleted files on a file system,  he can read all data on this file system. Even without   **e2undel**, a simple

**dd /dev/xxx**

reads the complete file system.

## NOTES

If you delete a file stored on an ext2 file system, its data is  not instantly lost. What happens is:

- •

  ext2 marks the file's data blocks as available in its block bitmap

- •

  ext2 marks the file's inode as available in its inode bitmap

- •

  ext2 sets the deletion time in the file's inode

- •

  ext2 invalidates the file's name in the directory entry

So, the file's data is not actually deleted (but it might be overwritten  in the  future); and the crucial information in the inode (owner, access rights,  size, data blocks occupied by the file and some more) is not touched.  If you know the inode number, you can recover the file by using  Ted Ts'o's [**debugfs**(8)](/debugfs/8.md) tool.

What is lost however is the association between the file name and the inode:  You can't restore the former file name from the inode information.  To recover the data of a deleted file, you must completely rely on the  information in the inode  like file size, owner, deletion time, etc.  ext3 behaves different from ext2 in one regard: When a file is deleted,  the information in the inode is also removed.   Tools like **e2undel** (or Ted T'so's [**debugfs**(8)](/debugfs/8.md)) that rely on this  information when undeleting files don't work anymore.

- libundel

  The undelete library uses standard mechanisms provided by the  glibc to hook into the system calls. On several systems, there were no  problems using the library. However, I did not test the library on a  heavily loaded server.

-

  libundel only works reliable if each process uses the library.  Problems arise from programs started by scripts that overwrite the  $LD\_PRELOAD variable (like **Netscape** does on some distributions); from processes that are started by init scripts  (i.e., before $LD\_PRELOAD is set); by using   [**su**(1)](/su/1.md) without a user name. The effect:   Not all deleted files are logged which might lead to confusion.

-

  For example: A process using libundel deletes a file: inode and name are logged  in **/var/e2undel/e2undel**. A new file is stored on this   inode and deleted by a process that does not use the undel library.  **e2undel** now finds this inode deleted,  finds the (older) entry in the libundel log, and concludes that both belong  together. When recovering the file, however, the recent information in the  deleted inode will be restored -- the data of the newer file is recovered  under the name  of the older one. This can be somewhat confusing.

- **e2undel**

  The program does not manipulate any internal ext2 structures, requires  only read access to the device it works on, and uses Ted Ts'o's ext2fs  library for all ext2 low level operations. I never observed any damage  to a file system treated with **e2undel**.

Files that were overwritten by [**mv**(1)](/mv/1.md)  and friends can't be recovered.

Processes that create and delete a lot of temporary files can flood the  log file with senseless information. The **/tmp** directory might be concerned, but also other directories like the user's   **Netscape** cache directories. In order to avoid  these confusing entries, it might be useful to shift these directories on  an own file system.

## AUTHOR

This man page was written by Helge Kreutzmann kreutzm@itp.uni-hannover.de and later improved by  Chris Niekel  for the Debian GNU/Linux project but may be used by others.

## SEE ALSO

[**debugfs**(8)](/debugfs/8.md),   **compactlog**(8),  [**file**(1)](/file/1.md),  **/usr/share/doc/e2undel/recovery-howto.html**,    *(link to URL http://e2undel.sourceforge.net/recovery-howto.html)*