Find the answer to your Linux question:
Results 1 to 2 of 2
i googled for help on ext3 undelete, but all i found was for ext2fs. can undelete be accomodated for an ext3 filesystem ??? ne suggestions?? thx ps - i posted ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Sep 2004
    Posts
    3

    Undelete on ext3fs - is it possible ??


    i googled for help on ext3 undelete, but all i found was for ext2fs.
    can undelete be accomodated for an ext3 filesystem ???
    ne suggestions??
    thx

    ps - i posted this on security, but i guess this is not a security issue

  2. #2
    Just Joined!
    Join Date
    Oct 2009
    Posts
    1

    Exclamation

    The first - file deletion on Ext3 works differently then on Ext2 file system and 'undelete' stragies for Ext2 will not work with Ext3.

    Some background:
    EXT2
    To delete file on Ext2 file system FS driver does the following steps (steps order doesn't matter at this point):
    1) Removes link from directory. This wipes reference to file inode number (only file name could remain on disk without reference to inode);
    2) Updates 'use count' for inode by doing decrement by 1.
    3) If no references to inode left (last hard link is deleted) - it marks inode as free (in inodes bitmap), puts there 'deleted date'.
    4) It releases file system blocks used by file just by updating bitmap (actual data still remains on disk until rewrite).

    This means deleted file information remains on disk. There are no file name linked to file, however all information about the file (size, allocation etc.) still remains on disk and could be easily fetched before rewrite with any other information.

    EXT3
    Ext3 file system is journalled so there are some different steps to delete a file:
    1) The driver removes link from directory. This only modifies internal linked-linst pointer and in most cases does not wipe nor inode reference, nor file name;
    2) It analyses 'use count' for inode by doing decrement by 1. If it is still not zero, it just updates inode.
    3) If no references to inode left (last hard link is deleted) - it marks inode as free (in inodes bitmap) and wipes it with zeros for crash-safety reasons. Because file system is journalled, the block with inode is copied to file system journal first.
    4) It releases file system blocks used by file just by updating bitmap (actual data still remains on disk until rewrite).

    If using same analysis like for Ext2, here (on Ext3) we have NO inode information and thus no data about file size and file allocation.

    That's why there are different technique that involves journal analysis. In case file system journal was not used much after file deletion (no writes to file system), the previous state block (with wiped inode) may still remain in journal, that's why it is possible to find this inode, link it with directory entry and get good file, even with real name.

    Unfortuanelly, this technique works for limited number of files (depends of journal capacity) and works until such record will be pushed off journal on some file system update (e.g. new file creation, modification etc.)

    For critical files when inode already lost it's still possible to apply search by file type technique, combined with indirect pointers tables detection. Sometimes this allows to guess first 12 blocks of file (12 direct blocks that were located in inode) and all subsequent blocks by indirect tables.

    Known software that does both kinds of analysis is commercial UFS Explorer Standard Recovery (this works since version 4). With more in-depth knowleage it also possible to use software like ext3grep.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •