First, I'd like to thank
James T &
ct64116 for their help on my first question; I accidentally overwrote an ext4 partition with the Windows 7 installer and lost something like 300Gb of files.
I took their advice and used testdisk to analyse the lost filesystem. Everything seems to be OK, and I was psyched about restoring it, but I've hit a speed bump.
I'm running Ubuntu 10.04 on a 64-bit processor. In order to repair the filesystem, I need to find the backup superblocks (which I've done already) and then use them to fsck the disk back into usable condition. But it's not working, and I think I know why.
I'm using this tutorial to get the partition up and running. However, when I run fsck.ext4, I get different output than he does. First of all, the version numbers are different: he has 1.41.4, I have 1.41.11.
Second of all, even though I'm running fsck.ext4, the error message I get back tells me that the filesystem I'm examining isn't a correct ext2 filesystem.
So I think that the problem here is that the version of fsck I have doesn't understand ext4 yet, and the reason it doesn't understand ext4 (even though the compile date on mine is later than his) is because I'm running a 64-bit system and the newer fsck hasn't been ported to 64-bit yet. Does this sound right?
Anyway, if there isn't a newer fsck for 64-bit systems, I think my only hope now is to pick up an external 3.5" enclosure, pull out the drive, hook it up to my i386 laptop, and attempt filesystem repair from that machine (which uses version 1.41.9).
Does this sound like a good idea? Does anyone know if there's a simpler way to fix this (like, if there is a 64-bit build of the newer fsck available - I can't seem to find much information through Google - it's a bit dense for me to digest)?
Thanks a ton.
edit: per nik's advice, here is the fdisk output for the system in question. The currently imperiled disk is the last in the list, at /dev/sdc1.
[nik edit: I've removed data from other disks to reduce clutter -- look at previous edit if it is required]
Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x05ced8ed Device Boot Start End Blocks Id System /dev/sdc1 1 182402 1465136128 7 HPFS/NTFS
UPDATE: I had no luck with the superblocks; however I was messing around with testdisk and I discovered that testdisk will copy out the folder structure into my home directory! HUZZAH
My home directory is on an SSD, though, and there is only about 30 gigs of space available at any given time, so I will have to stagger my copies and dump periodically to a larger platter - good thing I have an extra platter HDD available. I will just go through, folder by folder, until I've copied all the data out to the other disk. It will take time, but a lot less time than it takes to go through and rename EVERY SINGLE FILE, which is what I would have to do with photorec.
THANK YOU for all your help, especially you nik.