For a project for school I am making a program that can recover files from an ext2 file system. I have gotten to the point where I can find the deleted inodes. But when I go to read the pointers to the data blocks they have been zeroed out. From everything I have read this should not be the case, and by the sounds of it this is something that an ext3/4 file system would do. The command I use to create my test file system is mkfs.ext2 /dev/sdb in this case sdb is a flash drive. Are there flags that I am missing to create a legit ext2 file system or could it be with how its mounted? In my case i'm letting ubuntu auto-mount it.
Also I know that I am reading the inode correctly because sleuthkit is reporting the same about the inode data pointers being zeroed out.
I can't remember, but could the flash drive be deleting the data after the inode is wiped out? flash memory works differently from HDDs. the flash drive may be working the same way as an SSD.
output says that it is an ext2 /dev/sdb: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=c3280e16-c2a6-4af2-9247-5f8f0a6ca5cb, volume name "tset" (large files)
try making a partition, then formatting that ext2. that will be much more like a hard drive. then create your fs on the partition, and see if you can make it work.
Partitioning the drive should not make a difference. Make sure your files are getting written to the physical disk. Calling 'sync' after writing to the file and before removing might help. If all else fails, try it on a regular HDD.
Yea, I like already said I have team members that have tried this in a vm with a virtual HDD and they are seeing the same thing. My current theory is that the OS is creating a ext3 or 4 file system and changing flags so that it acts like an ext2, but because its really ext3/4 it is zeroing out the data block pointers.
If we can't figure this out our next plan of attack is looking into the journal and seeing if parsing through that is within the scope and time frame of the project.
If the same driver is used by ext2 and ext4, it could be doing this just because of using the same code for both. One idea might be to try different drivers, from FreeBSD or OpenBSD for example.
@Eden I have tried creating the file system explicitly without the journal with the -O ^has_journal flag but I am seeing the same results
@Dynamic_Gravity From what I read cfdisk only does the partitions... The following is all from a development vm where I have added a second HDD. I created the partition with: cfdisk /dev/sdb I then formated the new partition with mkfs.ext2 /dev/sdb1 and I get the following output:
Allocating group tables: done Writing inode tables: done Writing superblocks and filesystem accounting information: done
I then vi a file on the file system vi findme
Here is the fls output: root@ubuntu:~# fls /dev/sdb1 d/d 11: lost+found r/r * 12: .findme.swp r/r 13: findme d/d 655361: $OrphanFiles
As you can see the new file has a inode of 13. When we istat the inode we get: root@ubuntu:~# fls /dev/sdb1 d/d 11: lost+found r/r * 12: .findme.swp r/r 13: findme d/d 655361: $OrphanFiles
That was on a HDD in a VM. This showed 2 thing: First it doesn't matter if the file system is on a partition, and two we see the same behavior on the flash drive and the virtual HDD.
the flash drive may be overwriting the file .flash based drives dont delete files the same way as mechanical drives. mechanical drives just make the file as deleted and so it may be overwritten, flash based drives do wear leveling -actually overwrite the file- to help drive longevity. your virtual machine manager may be doing the same, but in the interest of drive space. the conclusion is the same as Dynamic_Gravity's try it on a real mechanical hard drive , and not on a virtual machine.
additionally try to mount it manually ie: mount -t ext2 /dev/blah /blah as opposed to automount. /*edit*/ cfdisk will assign a partition a file system, but it will not format the filesystem. this is useful in certain cases such as when a partition table is corrupt and you know the filesystem(s). ive recovered more than one machine with this from corrupt partition tables.
I have been having a nagging suspicion that something changed between when ext2 was used as to now, because there are a lot of these undelete programs out there. So I have created a ubuntu 6.06.2 vm with the disk fs as ext2. I created and deleted some files. I then imaged the system dd if=/dev/sda1 bs=1024 count=7000000 | nc * * and I saw that it treated the files correctly! I have now moved up to a 12.04 vm, I created one with the main fs as ext2 and the other vm the main fs was ext4 and a second hdd with ext2. Both Vms treated the files (the files on the ext2 fs) like it should in the documentation. I am going to try ubuntu 14.04 next and use the newest working OS as the testing platform for this project. I will report what I find later.