Like the ext3 file-system before it, ext4 is almost famuous for having no undelete facility. The ability to recover recently unlinked (deleted) files is something many users would like.
Ext3 file-system users have recently (2008) had the help of Carlo Wood's ext3grep tool which has greatly improved the chances of finding and recovering recently deleted files. Accidentally deleted files are usually in the category of recently deleted.
Accidents Will Happen
I'm here because a thoughtless script executed
rm -rf ../linux*
It wiped out my Linux kernel development git repository (./linux-2.6/). The system has a logical volume (LV) containing the ext4 file-system that is mounted to /home/all/SourceCode. With-in that is a directory for every source-code package I touch - there are hundreds. Amongst those is the directory that serves as the root of all my kernel development, with sub-directories for each repository I work with:
./linux-2.6/ # tracks Linus's tree and contains remotes from various other trees # (linux-pci, x86-tip, etc.) ./ubuntu-jaunty/ ./ubuntu-intrepid/ ./ubuntu-hardy/ ./linux-next/ # etc...
The script I used was one I'd not touched before, in the Ubuntu Jaunty repository (/ubuntu-jaunty/): debian/scripts/misc/prepare-ppa-source. It then executed the offending command:
rm -rf ../linux* include/config .config
which matched the ../linux-2.6/ directory. An earlier command in the script had issued an error message so I interrupted it with Ctrl+C - unfortunately not soon enough! I did notice that ../linux-next/ escaped because of that interruption.
Back-ups Are Not The Point
This being an active development tree that is constantly changing it only gets backed up every week or so. The changes in the repository over the intervening period are also quite widespread and involve the working-tree and the git repository itself.
Seeing as ext4 is backwards-compatible with ext3 it seems to make sense to extend ext3grep to, in effect, become ext4grep. I'm currently taking a crash-course in ext4 file-system design and structures alongside the same for ext3 (thanks to Carlo's fantastic documentation).
Next I shall get my head around Carlo's code and then develop a design and implementation plan to add ext4 structures, functions and options.
I've copied the file-system onto a spare hard disk which will become my working test bed - it can be the subject of write-tests as I proceed and be recreated from the original LV.
sudo lvdisplay /dev/Ubuntu/SourceCode --- Logical volume --- LV Name /dev/Ubuntu/SourceCode VG Name Ubuntu LV UUID AXViil-Kics-0kQa-4tLh-a9T3-2fAr-oIphgp LV Write Access read/write LV Status available # open 0 LV Size 30.00 GB Current LE 7680 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 252:7
sudo dumpe2fs -h /dev/Ubuntu/SourceCode dumpe2fs 1.41.4 (27-Jan-2009) Filesystem volume name: SourceCode Last mounted on: <not available> Filesystem UUID: 7e109a37-ffd8-4826-b54d-a2a28937406e Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 1966080 Block count: 7864320 Reserved block count: 392588 Free blocks: 5454071 Free inodes: 1468979 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1022 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 RAID stride: 32699 Flex block group size: 16 Filesystem created: Tue Feb 10 15:46:21 2009 Last mount time: Fri Mar 13 00:49:49 2009 Last write time: Sat Mar 14 01:09:01 2009 Mount count: 12 Maximum mount count: 20 Last checked: Tue Mar 3 12:13:29 2009 Check interval: 15552000 (6 months) Next check after: Sun Aug 30 13:13:29 2009 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: a281ded4-4e01-4485-a1d7-da1d34f19a49 Journal backup: inode blocks Journal size: 128M